Q: few questions about json construction

I was digging in json.hpp (v2.1.0) in order to understand how stuff gets created and check for unnecessary copies/allocations in simple cases like:
json x = { {"val1", 1}, {"val2", true} };

As I see it:

basic_json has expensive copy semantics as evidenced by it's cctor and op=:

    basic_json(const basic_json& other)
        : m_type(other.m_type)
    {
        ...
        switch (m_type)
        {
            case value_t::object:
            {
                m_value = *other.m_value.object;   <-- mem alloc + cctor call
                break;
            }
        ...

    reference& operator=(basic_json other) ...    <-- note lack of const&
    {
        ...
        using std::swap;
        swap(m_type, other.m_type);
        swap(m_value, other.m_value);

which means in my example we will end up copying the same data many times (depending how deep in hierarchy given piece of data is)

{"val1", 1} will be used to create a basic_json of type array that contains two basic_json objects of types string and whatever respectively (underlying vector will be allocated on heap, same for that string)

then it will be used to populate an std::map entry in basic_json object of type object here:

    basic_json(std::initializer_list<basic_json> init,
               bool type_deduction = true,
               value_t manual_type = value_t::array)
    {
        ...
            std::for_each(init.begin(), init.end(), [this](const basic_json & element)
            {
                m_value.object->emplace(*(element[0].m_value.string), element[1]);
            });

where m_value.object is of type std::map<string, basic_json> and emplace will end up passing a string& to related constructor (which will have to make another copy of a string)

and at some point initializer_list instances will be destroyed causing destruction of related basic_json objects and aforementioned vector and string objects will be deallocated

Please, correct me if this is incorrect or I missed smth important.
Now, as I see it there is a quick and easy way to avoid few copies:
m_value.object->emplace(std::move(*(element[0].m_value.string)), std::move(element[1]));

Q1: do you think it is ok? if not -- why?
Q2: this process has a lot of extra allocations (basic_json copies, underlying vectors and strings) -- is there an approach to construct my json object and avoid them?
Q3: pushing it further a bit -- inserting new sub-element into object means std::map lookup, can I avoid it somehow? For example by providing sub-elements in proper order and forcing related std::map::emplace/insert to use end() as a hint.

Q1: I've realized that std::initializer_list::begin/end() return T const* which can't be const_casted away with (very remote) possibility of problems if compiler somehow manages to put pre-created basic_json objects into read-only memory. This will never happen, but from purity standpoint I could see how this might be an obstacle...

I'll take a stab at this.
The lack of "const&" on the "assignment operator" is ok. This is a technique to avoid having to define two assignment operators (one lvalue const-ref, one rvalue-ref) that have identical implementations. Instead you pass-by-value and then rely on move+swap to get about the same thing.
Q1: No, this doesn't work because you cannot move-from a std::initializer_list :(  [see https://stackoverflow.com/questions/8193102/initializer-list-and-move-semantics#8193157]
If you're seeing a performance penalty using initializer-ilst construction, then you should use the other ways (eg, create an empty json::object, and then load it iteratively with the things). The initializer_list is a convenience but it will be faster to avoid it.
Q3: if you create a json::object, you can use the 'insert' function to insert a range of elements.

@jaredgrubb I am pretty sure it is ok to const_cast in this case -- basic_json object is non-trivial object with non-constexpr ctor, compiler simply can't pre-compute it (which is a requirement to be able to stuff it into read-only segment). But, yeah... purists will disagree

If you're seeing a performance penalty using initializer-ilst construction, then you should use the other ways

I apologize for my ignorance of nlohmann/json API, but what would be the alternative way to code this:
json x = { {"val1", 1}, {"val2", true} };

?

Nevermind, I think I pulled it apart:

Q1: can be done, but iffy (see above)

Q2: more efficient way would be smth like this:

json x;
x.emplace("val1", 1);
x.emplace("val2", true);

Q3: there is no (generic enough) ranged insert, nor hinted insert -- no way to avoid std::map lookups during basic_json population

Although casting away the const may appear to work, it's not legal to do so. You might get away with it on some versions of some compilers, but you should not rely on it. Seriously: avoid the temptation to work around the system on things like this. The more "hacks" you use, karma will bite you hard one day! (To be more technical about this, casting away the const is undefined behavior; eg, https://stackoverflow.com/questions/4042626/const-cast-and-ub).

It is certainly legal to do if you can prove that given reference points to a modifiable object in this particular case. That SO link doesn't tell the whole picture and there is a good reason why standard say "may" instead of "shall".
In case with initializer_list -- yes, you can argue that extremely smart compiler can potentially figure out details and put your list of very trivial basic_json objects into read-only segment. But in practice it will never happen -- not until you change your basic_json class to be smth like POD.

If you can prove a very specific thing like you describe about type definitions you control (or types whose behavior is explicitly defined), then const_cast is legal -- that's what it's for.
However, std::initializer_list is not a type you control and the standard says nothing about how it is implemented or how its elements are stored -- as you concede, smart compilers and library authors are permitted to be very clever.
Look, I am not arguing with your intuition here. I agree that "in practice", it'll probably just work on almost every compiler and library you try it on. Your reasoning is sound -- but that is not the same thing as whether you should write code that does it (answer: absolutely not; intentionally writing UB just because you can prove it works is not worth it).
Hopefully, one day, the standard will permit non-const initializer lists. It would be valuable. I'm sure we're not the first ones to want this, and there could be good reasons why it is not done (yet) or is impossible, and there may be no good reasons and it's just waiting for someone with enough initiative to shepherd it through.

it'll probably just work on almost every compiler and library you try it on.

I bet $50 -- as of now it works on every compiler that can compile this library :-)

However, std::initializer_list is not a type you control and the standard says nothing about how it is implemented or how its elements are stored ...

Actually standard does say few things about that -- for example elements are stored in contiguous memory.
You could also imply certain behavior even if standard doesn't promise it specifically. For example, the fact that initializer_list::begin() returns T const* implies that you can call it's const methods, which (as we know) can modify object state. So, unless compiler can prove that we don't -- it can't put that object in read-only memory and/or pool it (see "string pooling").
Can we guarantee that compiler won't be able to find out? I bet there is a way to do that (some weird method declaration?)... I don't know. For example, I can provide some level of assurance by declaring a "do-nothing" method (implemented in another translation unit) and call it. This will certainly work for any compiler that doesn't do link-time optimization.
In any case -- std::initializer_list definitely needs some improvement in standard... Pretty sure they'll add something along the lines of "non-trivial objects should not be stored in read-only memory".

Well, the compiler won't stop you from writing non-portable or UB.

The handling of initializer lists has been changed a bit in version 3.0.0 (see #663). I'm not sure whether it is relevant to this discussion, but I wanted to still let you know.

What do you propose to improve the code?

@crusader-mike Just for the record, please note that I am not an official representative of this project -- just an avid and eager user, supporter, and occassional contributor. I don't want any confusion that my opinions are those of the official maintainers.
I spent some time looking at that proxy class, and in my personal opinion, it looks great. I will remember that approach the next time I need to work around the lack of move support in std::initializer_list.
That said, I'll bow out of participating in this thread further since my engagements have not been helpful for you.

@jaredgrubb Oh, come on, dude -- I think this situation ended up being quite amusing. Happened to me many times in my life -- where I was absolutely sure in my correctness and yet somehow "failed to win". :)
@nlohmann Code is ok -- in light of my findings I am unlikely to use initializer_list-related functionality anyway. You may consider removing proxy class and replacing it with aforementioned one-liner (+const_cast) for simplicity. This won't fix problems mentioned in Q2. (and of course it may not work at all for some reason).
For Q2 you may consider changing proxy class -- make it represent (name+value) pair (instead of having two instances of proxy class). Not sure how it is going to play C++ rules related to brace-initializations, etc -- there is a chance it may just work. I.e. ideally this:
json x = { {"val1", 1}, {"val2", true} };

should result in creation of only two proxy objects where each one is (conceptually) a pair<string, basic_json> -- in related basic_json ctor you just move these elements to destination std::map instance. No wasted allocations this way...
There will be some trickery involved as (I assume) you'll also want to support constructs like this:
json x = { 1, 2, 3, 4}; // <-- builds array

tbh, I don't know about every usage pattern this library supports -- you should accept my recommendations with grain of salt.

@nlohmann another thing you may consider is storing std::string by value (in basic_json) -- modern implementation of std::string use SSO, you'll end up increasing size of basic_json a bit, but improving performance in typical case (of short field names) and half of Q2 problems gone,

... almost the same for std::vector -- if you hold it by value, you'll avoid one allocation in Q2. Unfortunately vector doesn't have any SSO equivalent, but if it had one (for size 2 or less) -- this would have solved second half of Q2 problems completely.

@jaredgrubb Thank you for your contributions! I do find them helpful, and I would like to keep you in the conversation - especially, since I lost track about that proxy class myself.
@crusader-mike I think your https://github.com/nlohmann/json/issues/1092#issuecomment-389936564 was lacking respect. Please note we have a code of conduct in this project. It's not about "being right" or "proving someone wrong" - it should be about helping each other out and improving the project.

Guys, you need a vacation. Seriously.

@nlohmann No need for thanks, I really appreciate the hard work you do in maintaining this awesome project. It's popular for a good reason!
@crusader-mike I love C++ and coming here is a kind of "vacation" to engage in interesting applications of nerdy edge cases of rvalues and such. But unless we're debating over a beer and have know each other a while, personal jabs ("high horses" and "vacations") will distract from your technical arguments. I encourage you to raise the professionalism a notch and you'll find a larger and more receptive audience for your ideas.


[WIP|RFC]: Add clang/llvm support

This now works with X86 only. We are able to build qemu targets and a few other
things.
This has been tested with upstream llvm distribution. Was not tested with
commercial compilers based on llvm.
This adds a 3rd party library to remove dependency on libgcc. Still looking
into how this can be done better with native clang.

Out of curiosity why does this only work on x86 at the moment?

it fails to build for ARM, the second architecture I tried. Could be something related to me doing something wrong. The failures are all related to inline asm code.

Any updates? Would be really great if I could use clang to build...

reset, starting a new PR


Export Past, Rose, Fell, etc from nmigen.hdl.ast

Nothing about Past, Rose, Fell, etc is formal-specific but currently these utility functions are only exported (well, glob-exported or whatever Python calls this) from nmigen.asserts. It would be convenient if they were available directly from nmigen.hdl.ast.

They are exported frmo nmigen.hdl.ast. That's where they're defined!

Do you mean "expose them from the prelude"?

I guess that's what I mean. They're not in the all list, I have to specifically go get them.
I'm bad at Python import rules...

Ok, so, that was actually intentional, because I didn't consider that they would be useful in normal code. (In SVA you can't use them in synthesis--in Yosys implementation of SVA you can, just like in nMigen.) And if they aren't useful in synthesis, then putting them in the prelude would have just polluted the namespace.
Do I understand it correctly that you found them useful? In things like edge detectors or FSMs, I assume? I'm essentially on board with adding them to the prelude already, but I'd still like to see the use cases you have to understand how broad their usefulness is.

Edge detectors exactly. It's not difficult to write one manually, of course, but why bother when Rose communicates the intent more clearly?
Also in my current state machine prototyping work I'm using Past to check "came-from" for on_entry triggers associated with transitions, which may or may not turn out to be The Right Way but it's something I'm doing. That's what prompted me to file this, although I've thought about doing so before.

Let's do this. Would you prepare a PR? When moving them to the prelude, you should add wrappers to nmigen.asserts to indicate that this module is deprecated. Then we can remove it once 0.3 is released.

Sounds good, will do.

It's not difficult to write one manually, of course, but why bother when Rose communicates the intent more clearly?

It also creates a more compact netlist (you get exactly one chain of registers per signal no matter how many of these operators you use).
However, there is a caveat. All of these implicitly created registers are reset_less. Do you foresee this being a problem? For example I'm not sure if this is the right thing for FSMs.

Actually, I think that caveat is important enough we should pause and think if this is really the right path. I'm worried about introducing a feature that will turn out to be a footgun.
The main argument in favor of Past, etc, being language features (beyond the assertion sub-language) is that they take their clock domain from the context they're used in, which is handy, and means you don't need to write sampling registers by hand. But that same convenience and concisenes could be a drawback.

Good question. My intuition would be that e.g. Rose would always output 0 immediately after a reset, which wouldn't necessarily be true if the generated registers are reset_less. I agree with pausing here for further thought.
Is there a reason they must be reset-less in the formal use case?

Is there a reason they must be reset-less in the formal use case?

I remember that I made them reset-less deliberately while writing testbenches for AsyncFIFO. I think that before I did so, I had an issue where the reset-ful nature of those implicit registers was hiding a bug in the reset logic by virtue of, well, resetting the testbench with the design.

Hm. I wonder if we could just add the reset_less parameter to the Rose et al objects(?). It does make sense that in formal mode, you'd want Fell if reset caused a signal to fall, for example.
Another thought is to add something like EdgeDetector(edge="pos", reset_less=False) to ast and export an alias from asserts which is Rose = EdgeDetector(edge="pos", reset_less=True) (and the corresponding for Fell).

Hm. I wonder if we could just add the reset_less parameter to the Rose et al objects(?). It does make sense that in formal mode, you'd want Fell if reset caused a signal to fall, for example.

We could of course do that, but it seems like it would impact ergonomics either in the formal case, the synthesis case, or both, since I think the defaults for these are different.

Another thought is to add something like EdgeDetector(edge="pos", reset_less=False) to ast

Sure, we could do it in principle, but it seems like special-casing some fairly boring functionality in a way that is too specific. I thought it's OK to special-case for SVA because, well, I'm not about to invent a whole new verification sub-language and SVA seems really well-designed. But if we're generalizing them, it seems like an issue.

We could always just not do this at all. It's really not that big of a deal to write my own edge detectors.

Let's not do this for now, and reconsider it if someone makes a good case for the usefulness of these operations in the prelude. I think these operations is something that would be nice to have in principle, but more work is necessary to make sure we won't regret adding them.


Add next_scheduled_collections function

[ ] Add function to retrieve next scheduled collections for a specific location (for next day or all of the future ones)
[x] Create Core.Application and move application related callbacks in there

Adaptation to timezones in locations must be done before having the functionality intended in this PR


generateDocumentation fails when there is @throw in the noncompliant block

Expected Behavior
While writing @throws before function, in either noncompliant or compliant block should not fail the ./gradlew generateDocumentation command
Observed Behavior
./gradlew generateDocumentation  fails with the below stack trace when there is mention of @throws in noncompliant or compliant block
Gradle Stacktrace
Exception in thread "main" io.gitlab.arturbosch.detekt.generator.collection.exception.InvalidCodeExampleDocumentationException: Invalid rule documentation for noncompliant and compliant code examples in Rule SuspendFunInsideRunCatching contains an incorrect noncompliant code definition.
        at io.gitlab.arturbosch.detekt.generator.collection.DocumentationCollector.extractNonCompliantDocumentation(DocumentationCollector.kt:43)
        at io.gitlab.arturbosch.detekt.generator.collection.DocumentationCollector.extractRuleDocumentation(DocumentationCollector.kt:30)
        at io.gitlab.arturbosch.detekt.generator.collection.DocumentationCollector.setClass(DocumentationCollector.kt:22)
        at io.gitlab.arturbosch.detekt.generator.collection.RuleVisitor.visitClassOrObject(RuleVisitor.kt:112)

Steps to Reproduce
Comment used to repro the scenario with the above crash
/**
 *
 * <noncompliant>
 * @Throws
 * </noncompliant>
 *
 * <compliant>
 *
 * </compliant>
 *
 */

Context
 Not able to use `@Throws(IllegalStateException::class)` while describing a method in these blocks

Did you try with @@Throws? @ is a special character on kdoc. For that reason we have @@ ss a way to scape it.

Hi @BraisGabin yes 😅. I forgot the escaping. Sorry for the false alarm


Update index 2 md.rst

Minor mechanics. Figuring out file names, this should probably be BLT md.rst

I give up I shouldn't have left this PR for so long and now the file has been moved.  Unless you want to fix the PR, i am going to close it and copy the file changes into a new PR.  Thanks @davis274


For each loops do seemingly unintended copies

Beast version 55
Steps necessary to reproduce the problem
The default CMake build
All relevant compiler information
Compiling with clang 4.0 with the CXX flag -Wrange-loop-analysis indicates that several for each loops do a copy instead of getting elements by reference.
For instance
/Users/mgwong/Beast/test/core/buffer_bench.cpp:69:25: warning: loop variable 'buffer' is always a copy because the range of type 'const beast::basic_multi_buffer<std::__1::allocator<char> >::mutable_buffers_type' does not return a reference [-Wrange-loop-analysis]         for(auto const& buffer : buffers)
This seems to be due to a number of using reference = value_type; instead of using reference = value_type&; throughout several classes.
beast-warnings.txt

Its not a problem of the loops but rather, because the ranges returned by functions like buffer_prefix and buffer_cat return values instead of references. This is a problem in the C++ Standard, which is partially addressed by the Range v3 proposal. I am also attempting to address it in the Networking-TS:
https://cplusplus.github.io/LWG/lwg-active.html#2779
You could change the loop:
for(boost::asio::const_buffer const buffer : buffers)

If you would like to submit a pull request with this change, and it silences the warnings, I would strongly consider merging it.

Sorry, I'm a bit confused. ForwardIterator currently dereferences to a lvalue reference. Your proposal is to allow it to dereference to an rvalue. Could you please elaborate more on why buffer_cat can't return a reference?

ForwardIterator currently dereferences to a lvalue reference

That's a problem, but if it was just that it could be worked around. This is a bigger problem:
From http://en.cppreference.com/w/cpp/concept/ForwardIterator
"If a and b compare equal (a == b is contextually convertible to true) then either they are both non-dereferenceable or *a and *b are references bound to the same object"
That means that when dereferenced, two different iterators must point to the same location in memory. This rules out returning a member of the iterator, i.e. "stashing" a value_type in the iterator itself.
buffer_prefix_view returns a modified copy of the value from the range it adapts:
https://github.com/vinniefalco/Beast/blob/master/include/beast/core/impl/buffer_prefix.ipp#L92
Even worse, buffer_cat is capable of wrapping a series of buffer sequences with different value types (they are converted to all mutable_buffer or const_buffer). How could we return a reference? Note that iter<I>() in the code below can return a different type for each value of I:
https://github.com/vinniefalco/Beast/blob/master/include/beast/core/impl/buffer_cat.ipp#L252
I tried all sorts of ways to make it a reference but I failed. If you would like to try, you have my support. But I don't think its possible.

Upon further research, I think that modifying the range-for loops in the Beast implementation is warranted. Given the specifications of ConstBufferSequence and MutableBufferSequence, specifically that the iterators they provide are convertible to const_buffer and mutable_buffer respectively, the loops should be written as:
for(boost::asio::const_buffer const buffer : buffers)
    ...

for(boost::asio::mutable_buffer const buffer : buffers)
    ...

There is precedent, Asio implementation does the same thing:
https://github.com/boostorg/asio/blob/develop/include/boost/asio/buffer.hpp#L1412
and
https://github.com/boostorg/asio/blob/develop/include/boost/asio/buffer.hpp#L1415

Thanks for the explanation.
After experimenting, I found that due to templates, most of the occurences of this warning can't easily be corrected because -Wrange-loop-analysis also warns if you copy unnecessarily. Sometimes using references doesn't do a copy and sometimes it does, so I think the preferred solution in this case is to just ignore the warning.

It should be fixed in v56, I don't see any warnings (and they are turned on now): https://github.com/vinniefalco/Beast/commit/f8fb4d9036efca300086ac8e6ac295c89386dc3f


[flags] add options for less file output

This PR adds two flags:

-no-pcap: not generate Pcap file
-no-replay: not generate Replay file

Got this idea when my stress test pcap filled up my whole disk.

@wgtdkp any comment for this simple PR ?

Codecov Report

Merging #83 into master will decrease coverage by 0.13%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #83      +/-   ##
==========================================
- Coverage   39.92%   39.79%   -0.14%
==========================================
  Files          16       16
  Lines        2447     2450       +3
==========================================
- Hits          977      975       -2
- Misses       1450     1455       +5
  Partials       20       20

Impacted Files
Coverage Δ

dispatcher/dispatcher.go
0.00% <0.00%> (ø)

web/web.go
42.02% <0.00%> (-2.90%)
:arrow_down:

Just curious, How long does it take to exhaust your disk?

It depends on the volume of the Thread traffic.


Error generating code. Check the Developer Console for details. Feel free to open a Github issue

I can't generate code. please help me..!

same for me. The code exists but isn't functional, missing parts and incorrect syntax here and there, which is probably why the previews doesn't render.

me too

@abi could you just provide us more detail about this issue
It would be helpful

Going to need your backend logs to debug this. If you look at the backend logs, check the FAQ section to see if the fixes there solve it.

me too

@tanphat2k4 đã fix được chưa hả ông?

@tanphat2k4 đã fix được chưa hả ông?

chưa bạn ơi :)

same error for me. Even when using your hosted version. Nothing is created.
Cool app and concept.

same here. I dot this https://github.com/abi/screenshot-to-code/issues/3#issuecomment-1814777959 but doesn't works :/

Hi yall please post your backend logs so we can debug. Without that there's no information to know why code generation failed.

Hi yall please post your backend logs so we can debug. Without that there's no information to know why code generation failed.

it finally works. I've redone the installation and the code is now properly generated.

same error here

@abi  backend logs
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     await func(session)
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/fastapi/routing.py", line 289, in app
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     await dependant.call(**values)
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/app/main.py", line 117, in stream_code_test
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     completion = await stream_openai_response(
2023-11-21 16:51:58 screenshot-to-code-backend-1   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/app/llm.py", line 23, in stream_openai_response
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     completion = await client.chat.completions.create(**params)
2023-11-21 16:51:58 screenshot-to-code-backend-1   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/resources/chat/completions.py", line 1191, in create
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     return await self._post(
2023-11-21 16:51:58 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1474, in post
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
2023-11-21 16:51:58 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1275, in request
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     return await self._request(
2023-11-21 16:51:58 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^^^^
2023-11-21 16:51:58 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1318, in _request
2023-11-21 16:51:58 screenshot-to-code-backend-1   |     raise self._make_status_error_from_response(err.response) from None
2023-11-21 16:51:58 screenshot-to-code-backend-1   | openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model gpt-4-vision-preview does not exist or you do not have access to it. Learn more: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}
2023-11-21 16:51:58 screenshot-to-code-backend-1   | INFO:     connection closed
2023-11-21 23:05:02 screenshot-to-code-backend-1   | INFO:     Shutting down
2023-11-21 23:05:02 screenshot-to-code-backend-1   | INFO:     Waiting for application shutdown.
2023-11-21 23:05:02 screenshot-to-code-backend-1   | INFO:     Application shutdown complete.
2023-11-21 23:05:02 screenshot-to-code-backend-1   | INFO:     Finished server process [1]
2023-11-21 23:05:02 screenshot-to-code-backend-1   | Using OpenAI API key from client-side settings dialog
2023-11-21 23:05:02 screenshot-to-code-backend-1   | generating code...
2023-11-21 23:05:13 screenshot-to-code-backend-1   | Skipping virtualenv creation, as specified in config file.
2023-11-21 23:05:14 screenshot-to-code-backend-1   | INFO:     Started server process [1]
2023-11-21 23:05:14 screenshot-to-code-backend-1   | INFO:     Waiting for application startup.
2023-11-21 23:05:14 screenshot-to-code-backend-1   | INFO:     Application startup complete.
2023-11-21 23:05:14 screenshot-to-code-backend-1   | INFO:     Uvicorn running on http://<IP_ADDRESS>:7001 (Press CTRL+C to quit)
2023-11-21 23:06:25 screenshot-to-code-backend-1   | INFO:     ('<IP_ADDRESS>', 34098) - "WebSocket /generate-code" [accepted]
2023-11-21 23:06:25 screenshot-to-code-backend-1   | INFO:     connection open
2023-11-21 23:06:32 screenshot-to-code-backend-1   | ERROR:    Exception in ASGI application
2023-11-21 23:06:32 screenshot-to-code-backend-1   | Traceback (most recent call last):
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/uvicorn/protocols/websockets/websockets_impl.py", line 247, in run_asgi
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     result = await self.app(self.scope, self.asgi_receive, self.asgi_send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/uvicorn/middleware/proxy_headers.py", line 84, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     return await self.app(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/fastapi/applications.py", line 276, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await super().call(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/applications.py", line 122, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.middleware_stack(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/middleware/errors.py", line 149, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.app(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/middleware/cors.py", line 75, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.app(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 79, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     raise exc
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 68, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.app(scope, receive, sender)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/fastapi/middleware/asyncexitstack.py", line 21, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     raise e
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/fastapi/middleware/asyncexitstack.py", line 18, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.app(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/routing.py", line 718, in call
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await route.handle(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/routing.py", line 341, in handle
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await self.app(scope, receive, send)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/starlette/routing.py", line 82, in app
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await func(session)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/fastapi/routing.py", line 289, in app
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     await dependant.call(**values)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/app/main.py", line 117, in stream_code_test
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     completion = await stream_openai_response(
2023-11-21 23:06:32 screenshot-to-code-backend-1   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/app/llm.py", line 23, in stream_openai_response
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     completion = await client.chat.completions.create(**params)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/resources/chat/completions.py", line 1191, in create
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     return await self._post(
2023-11-21 23:06:32 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1474, in post
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
2023-11-21 23:06:32 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1275, in request
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     return await self._request(
2023-11-21 23:06:32 screenshot-to-code-backend-1   |            ^^^^^^^^^^^^^^^^^^^^
2023-11-21 23:06:32 screenshot-to-code-backend-1   |   File "/usr/local/lib/python3.12/site-packages/openai/_base_client.py", line 1318, in _request
2023-11-21 23:06:32 screenshot-to-code-backend-1   |     raise self._make_status_error_from_response(err.response) from None
2023-11-21 23:06:32 screenshot-to-code-backend-1   | openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model gpt-4-vision-preview does not exist or you do not have access to it. Learn more: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}
2023-11-21 23:06:32 screenshot-to-code-backend-1   | INFO:     connection closed

@abi do i need to use Gpt 4 api ?

@Adarsh7825 yes: {'error': {'message': 'The model gpt-4-vision-preview does not exist or you do not have access to it. Learn more: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}
See https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4

Hi yall please post your backend logs so we can debug. Without that there's no information to know why code generation failed.

it finally works. I've redone the installation and the code is now properly generated.

hi @nicolastilly , I have a question : you are using chatGPT4.0.?


translate docs to Russian

This may sound a silly question: But can said person use Google Translate or is it preferred that said person/people should speak Russian to be able to accomplish this task?
[SideNote] If no Russian is available with free time to contribute, but has a task of that entails using Rxjs docs, It probably would be a good idea as a place holder, for docs to be translated with google Translator for developers to use. Until an actual Russian can iron out a few wrinkles & perfect the docs in his language.

It is extremely hard to track machine translated contents as placeholder to actual translated contents and most cases I haven't seen those process speeds up translation but just causes more confusion to readers. If there isn't someone can work on certain languages it'd fine, but I'm going to object to fill in via machine translations.

You can assign this issue to me, I'll do the translation once we choose translation tools :)


Build fails

With Python 2.7 and Ubuntu 18.04, after running this line:
python build/build.py --enable_cuda
I get the following errors:
Building XLA and installing it in the jaxlib source tree...
DEBUG: /home/chen/.cache/bazel/_bazel_chen/e15eb051390cace74a40a2626236fc36/external/bazel_tools/tools/cpp/lib_cc_configure.bzl:118:5:
Auto-Configuration Warning: 'TMP' environment variable is not set, using 'C:\Windows\Temp' as default
INFO: Analyzed target //build:install_xla_in_source_tree (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /home/chen/.cache/bazel/_bazel_chen/e15eb051390cace74a40a2626236fc36/external/com_google_absl/absl/hash/BUILD.bazel:28:1: C++ compilation of rule '@com_google_absl//absl/hash:hash' failed (Exit 1)
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
Target //build:install_xla_in_source_tree failed to build
ERROR: /home/chen/.cache/bazel/_bazel_chen/e15eb051390cace74a40a2626236fc36/external/org_tensorflow/tensorflow/compiler/xla/python/BUILD:242:1 C++ compilation of rule '@com_google_protobuf//:protoc_lib' failed (Exit 1)
INFO: Elapsed time: 0.494s, Critical Path: 0.10s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
FAILED: Build did NOT complete successfully
Traceback (most recent call last):
File "build/build.py", line 334, in
main()
File "build/build.py", line 329, in main
[":install_xla_in_source_tree", os.getcwd()])
File "build/build.py", line 50, in shell
output = subprocess.check_output(cmd)
File "/home/chen/anaconda3/envs/LFADS/lib/python2.7/subprocess.py", line 223, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['/home/chen/bin/bazel', 'run', '--verbose_failures=true', '--config=mkl_open_source_only', '--config=cuda', ':install_xla_in_source_tree', '/home/chen/jax/build']' returned non-zero exit status 1
Any help would be much appreciated.

It sounds to me like you don't have a C++ compiler installed or it isn't working for some reason. Can you double check that?
Try something like
sudo apt-get install build-essential python3-scipy cython3
python3 build/build.py

I'll confirm exactly which packages are needed.


sanitizedHtmlFromHtml nil arg check

Related to #23 causing #49 CC: @danieldickison
result/html is nil sometimes. Not sure why atm but this causes an infrequent crash
https://github.com/apparition47/MailTrackerBlocker/blob/091cd4879d642a0072b30c605ed35383aab52c92/Source/MTBBlockedMessage.m#L68

Maybe text-only emails?


net/devnet

Implement Bitcoin devnet under scripting

check : https://github.com/KasarLabs/net/pull/9


Exclude new Kotlin Test directories in default config

Expected Behavior
A project using kotlin's new source directory structure does not enforce rules like lateinitusage for files in src/androidUnitTest/** and src/androidInstrumentedTest/** when using the default configuration.
Current Behavior
rules that are excluded by tests in the default config should also be excluded in the new test folder structure.
Context
Kotlin 1.8 introduces a new folder structure https://kotlinlang.org/docs/whatsnew18.html#sourcedirectories
The default detekt configuration file excludes a bunch of different variants of test source sets by default.
It would be nice to either add the new androidUnitTest and androidInstrumentedTest to those defaults as well, or maybe even better, build in support for defaulting all test source sets to be excluded (not sure how feasible that is).

It would be nice to either add the new androidUnitTest and androidInstrumentedTest to those defaults as well, or maybe even better, build in support for defaulting all test source sets to be excluded (not sure how feasible that is).

I believe the best would be to add **/androidUnitTest/** and **/androidInstrumentedTest/** to our default excludes as suggested 👍

Adding this issue the next release milestone as the main branch is already on Kotlin 1.8


Do not create separate worker file if inline == only

#20

can you please merge because this is a vital patch

@tjenkinson Can you sign the CLA?

done

@Heedster can this go in? Would be a major relief ...

@drcmda The maintainers need to merge it. My work is done.

@sokra Please merge

@sokra Bumping for attention. Is this the correct direction? If not let's provide some feedback so we can get this taken care of during RC feedback period.

Why is no one replying about this?

@Heedster, please keep in mind that we are all very busy with webpack 2 and this is not our full-time job. Before merging someone needs to verify this works and review the code, and that takes time. We haven't forgotten about this.

can you please merge because this is a vital patch

really? This only removes one emitted file. It's only a optimization.

My work is done.

Your PR doesn't contain tests. I know that there is not test infrastructure for this loader, but no tests make it difficult for me to validate this. I need to test it manually. This means a lot work and I don't have time for this currently.
If you want to get this merged, start by improving this repo with test infrastructure, tests, linting, etc. and you can become maintainer.


Homebrew (mac) installer should not install dartium and/or content-shell with -dev

They are more than broken.
Something needs to be changed here: https://github.com/dart-lang/sdk/blob/26c06cdd825fb22990768fcf5c4ffb753a4ccd62/tools/apps/update_homebrew/lib/update_homebrew.dart#L112
@nex3 – any ideas how to do this cleanly-ish w/ Ruby?

...at a minimum we should warn folks...

This is less a Ruby question and more of a Homebrew API question, which I'm unfortunately not very familiar with.

CL https://dart-review.googlesource.com/c/sdk/+/48000


Keyboard transition show Scaffold background color

Code to Reproduce
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.red,
      body: SingleChildScrollView(
        child: Container(
            color: Colors.white,
            width: MediaQuery.of(context).size.width,
            height: MediaQuery.of(context).size.height,
            child: Column(
              children: [
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
                TextFormField(),
              ],
            )),
      ),
    );
  }

Step to reproduce
Click any field that will be underneath the keyboard and you should see the background color appearing.
You will see it even better when the keyboard closes.
Demo
Like here you can see that the scaffold color is appearing instead of being transparent

Hi @Andrflor, Thanks for filing the issue. I am able to reproduce the same behavior on stable and the master channel.

This may an example of aknown problem with antialiasing and mapping from logical pixels to device pixels. There's an open issue for a documentation fix: #14288
More info about the problem can be found here:
https://github.com/flutter/flutter/issues/14288#issuecomment-361375791
https://github.com/flutter/flutter/issues/17084#issuecomment-385718108
https://github.com/flutter/flutter/issues/15035#issuecomment-370028740

Closing as duplicate of #14288


Missing circular support base part in UR5 model

The circular support ring seems to be missing from the UR5 STL files. For clarity, this part appears at the bottom, connected to the base in the final render.

Sorry about that! The ring was remove in the final release. I will update the image to avoid future confusion


Resolves #10 Http client timeout

Coverage increased (+0.009%) to 96.447% when pulling 83a58e93755df425697d58098946d0141dac68f5 on http-client-timeouts into 53fd75c5d7d98d1d5e2bb3ab9b3bfca8e140401e on master.


TurtleBot3 LDS-01

Hi, I'm totally new to electronics and programming. My question is, is there any way to change pwm and/or the rpm of the LIDAR from the TurtleBot3 kit? Thank you.

Hi, @garinalham :)
Unfortunately, the speed of the LDS-01 can not be changed. Because this function is in firmware.
Could you tell me that why you want to change the speed of the LDS? I will help you if I can.

Thanks for the respond! Yeah, I need to see how different scanrate affect the mapping result. Or do you have any alternative to this? Or should I just update the map_update_interval?

Yes... To control the map_update_interval is best way. But, now I have a idea.
How about change map_metadata topic rate? This link will help you.
http://wiki.ros.org/gmapping
Thanks,
Gilbert

Thanks! That was quick :). Can you elaborate what parameters is there in the map_metadata to tinker with? Perhaps a close replacement to the LIDARS rotational speed.

I am glad that the problem has been solved.
Please, let me know if you have any questions on this issues.
Thanks,
Gilbert

This issue will be closed since there were no actions for a while. You can reopen this issue to show this issue to the users whenever. Thanks.