Is it possible to use ScrollScrubber on horizontal scrolling?

Thank for your framework. I really like it. I am not sure that it is an issue but I can not understand is it possible to use ScrollScrubber element in horizontal scrolling mode? And if no, I wonder are you going to add this feature soon?

Hey @tiana890, it is not an issue, we don't have implemented yet.
Two options, you can help us on this implementation, I think that it is not complicated.  I am working on another features right now, or you can wait, I will probably implement this some day.


How to get user_id by phone number without ImportContacts

Other than ImportContacts, Is there anyway to know the user_id by phone number?
Or at least a way to realize that a phone number is registered in telegram or not...

There is no method in the Telegram API, which is supposed to return this information because of privacy concerns. ImportContacts and some other methods return user_ids by a phone number as a side effect, but all such methods are subject to very tight server-side flood control, which prevents them from such usage.

Okay, at least is there any method to show up whether a phone registered in telegram or not?

There is no method in the Telegram API, which is supposed to return this information, because of privacy concerns. ImportContacts and some other methods return user_ids by a phone number as a side effect, but all such methods are subject to very tight server-side flood control, which prevents them from such usage.

Could you please mention a valid link or reference about those tight server-side controls?

Thanks, How bad are those tight flood controls? How long does it take for telegram to get rid of it? How long after would telegram put the victim into whitelist?

They are very tight. That's all I can tell.

The correct approach is to create a special bot, which will send the image of the receipt, to users and use Telegram login widget on the site to allow users to subscribe for receipt receiving through the bot.

Yeah, it might be a workaround, but the customers I'm talking about mostly do not care about bots or more precisely do not trust them. in other words, they'd prefer to get in touch with real persons. Is there any other approach other than utilizing bots?

Like, say, what happens if I call ImportContacts once every 6 hours and add 3 to 5 contacts every time. I mean my customers (those who are newcomers) would have to wait 6 hours to get added into account. and then I'd send the images to them.

@Salardx, @levlam wants to say that this library is for writing clients for humans, not for automatic bots. Accordingly, the limits should be similar to human behavior without specific numbers. Limits are not the concern of tdlib.

@Salardx, @levlam wants to say that this library is for writing clients for humans, not for automatic bots. Accordingly, the limits should be similar to human behavior without specific numbers. Limits are not the concern of tdlib.

I understand, but my customers want human too...

@Salardx There is no other approach, because such tasks are supposed to be automatically done by bots without any delays and restrictions after user willingly subscribes for receiving messages from the bot. Your approach with ImportContacts will completely stop working in a few hours or a few days. Corresponding user account can be also blocked for spam if any user report it.

use signal ?


Add stackTrace property to fiber

I was writing a small test runner and noticed that after calling fiber.try, you can only obtain the error text but not the location where the error occured, which makes debugging very cumbersome.
I added fiber.stackTrace in addition to fiber.error. The stack trace is formated on the fly, which means there is no additional performance overhead if you don't use the property.
This also works for fibers which are yielded. It will return null if the fiber hasn't run yet or returned already.
I added two additional tests to show how it works.
var fiber = Fiber.new {
  "s".unknown
}

System.print(fiber.stackTrace) // expect: null
System.print(fiber.try()) // expect: String does not implement 'unknown'.
System.print(fiber.stackTrace) // expect: at new(_) block argument:(main) line 2\n

EDIT: Looks like some commits show up here that should be in main already. Basically, I only want
e3f1774 and ad05671. Anyone knows some git magic on how to fix that?

If this is a bug, don't try(): let the fiber kill your program and the stack trace will be printed.

often you want resilience as well as information, which this PR aims for.

Logging and so?

This is not resilient:

let the fiber kill your program

I think there are valid use cases, where you want a detailed error report without killing the vm.

A test runner that should continue when a test fails
A scheduler which runs several fibers in parallel
A web server that will report an error if one request fails

A web server that will report an error if one request fails

Logging and so?

Anyway, remove what I said 😄 You're right.

Incidentally, doest it work on new fiber and yield fiber? And does it out
something useful?

It would be good to try to compress the stack trace in case of infinite
direct recursion. Since the trace as limited output, it possible to not see
where the error started.
In addition if the stack trace get trunckated there should be an indication
of the situation, so the user does not get confused.

@mhermier It returns null for a new Fiber and works correctly on a yielded Fiber. The current implementation will stop walking the stack after the 16kb buffer was filled.

(sorry for the noise)
Maybe a better solution would be to allow to iterate on stack frames
entries, and let wren make the string.
It is suboptimal, may have memory implications, but it should be easier to
let the user customize the stack trace output.

Maybe a better solution would be to allow to iterate on stack frames

They meant for debugging and not for text processing, IMO. You can process the stack trace and find the function names etc., that reminds me what angularjs used to do... :P

(sorry for the noise) Maybe a better solution would be to allow to iterate on stack frames entries, and let wren make the string. It is suboptimal, may have memory implications, but it should be easier to let the user customize the stack trace output.

I thought about that but felt that the additional complexity was not worth it

Yes but that info can be used in plain text, viewed inside a debugger and
displayed in columns in a table, the user can make a stack trace formatter
more to it's liking, or whatever.
And more importantly, we have access to the whole trace, and not possibly a
truncated version of it.

Yes but that info can be used in plain text, viewed inside a debugger and displayed in columns in a table, the user can make a stack trace formatter more to it's liking, or whatever. And more importantly, we have access to the whole trace, and not possibly a truncated version of it.

I see the benefits too, I just don't see a simple way of doing it. This means we would need to make some kind of "StackIterator" available that let's you iterate "StackFrame" objects both exposed to wren. Right?

A simple solution is to do like string does with StringByteSequence. Do something like:
class Fiber {
  foreign _string.iterateStackFrames_(iterator)
  foreign _string.moduleToStringAt_(iterator)
  foreign _string.functionToStringAt_(iterator)
  foreign _string.lineAt_(iterator)

  stackTrace { StackStrace.new(this) }
}

// Lazy implementation example
class StackFrame {
  construct new_(fiber, iterator) {
    _fiber = fiber
    _iterator = iterator
  }

  module  { _fiber.moduleToStringAt_(_iterator) }
  function { _fiber.functionToStringAt_(_iterator) }
  line        { _fiber.lineAt_(_iterator) }

  toString { "at %(module):%(function ) line %( line )" }
}

class StackTrace is Sequence {
  construct new(fiber) {
    _fiber = fiber
  }

  iterate(iterator) { _fiber.iterateStackFrames_(iterator) }
  iteratorValue(iterator) { StackFrame.new_(_fiber, iterator) }

  toString { joint("\n") }
}

The implementation can be lazy or not. Going not lazy has the advantage of being able to compare stacks/make them easy to compare trivially, and could be helpfull in case of implementing a debugger that allows to trace instructions. But it is not an absolute requirement, since if we have access to the data we can make a copy of it.

If we don't want to bloat core, another possibility is to move this to an extra module and move the foreign functions to StackFrame and change arguments to (fiber, iterator) in the signature.

A simple solution is to do like string does with StringByteSequence. Do something like:
class Fiber {
  foreign iterateStackFrames_(iterator)
  foreign moduleToStringAt_(iterator)
  foreign functionToStringAt_(iterator)
  foreign lineAt_(iterator)

  stackTrace { StackStrace.new(this) }
}

// Lazy implementation example
class StackFrame {
  construct new_(fiber, iterator) {
    _fiber = fiber
    _iterator = iterator
  }

  module  { _fiber.moduleToStringAt_(_iterator) }
  function { _fiber.functionToStringAt_(_iterator) }
  line        { _fiber.lineAt_(_iterator) }

  toString { "at %(module):%(function ) line %( line )" }
}

class StackTrace is Sequence {
  construct new(fiber) {
    _fiber = fiber
  }

  iterate(iterator) { _fiber.iterateStackFrames_(iterator) }
  iteratorValue(iterator) { StackFrame.new_(_fiber, iterator) }

  toString { joint("\n") }
}

The implementation can be lazy or not. Going not lazy has the advantage of being able to compare stacks/make them easy to compare trivially, and could be helpfull in case of implementing a debugger that allows to trace instructions. But it is not an absolute requirement, since if we have access to the data we can make a copy of it.

Thats also what I was thinking of. I think C# does a similar thing. I have a few concerns about this. Bloating core and the overall code base is one of them, I also think we will need to exchange the iterator with a pre-filled list. Otherwise we would be able to run the fiber between iterations, which sounds like a recipe for disaster.
I would definitely be willing to give such an implementation a try but I would like to hear some more opinions on that before putting any more work in it.

One solution to mitigate the bload is to lazy import StackTrace by doing:
class Fiber {
  stacktrace {
    import "what_ever_module_name" for StackTrace
    return StackTrace.new(this)
  }
}

One solution to mitigate the bload is to lazy import StackTrace by doing:
class Fiber {
  stacktrace {
    import "what_ever_module_name" for StackTrace
    return StackTrace.new(this)
  }
}

Possible but using a module external of core for accessing Wren internals seems a little odd. It might be possible to expose stack-walking functionality to the public C Api and let people implement the functionality themselves - but this seems overly complex to me

Just thought about a simpler implementation that don't need a separated module:
class Fiber {
  foreign iterateStackFrames_(iterator)
  foreign moduleAt_(iterator)
  foreign functionAt_(iterator)
  foreign lineAt_(iterator)

  stackTrace {
    var trace = []
    stackTrace {|module, function, line|
       trace.append("at %( module ):%( function ) line %( line )")
    }
    return trace.join("\n")
  }

  stackTrace(cb) {
    var iterator = null
    while (iterateStackFrames_(iterator)) {
      cb.call(moduleAt_(iterator), functionAt_(iterator), lineAt_(iterator))
    }
    return cb
  }
}

@mhermier looks good. I'll have a look into it.

For implementation of the primitives make the things simple. Iterator is
the index on the array, and make iterate skip the unwanted indexes. That
way a count primitive can be added so we can also visit the full stack
indexes.

I now thought about another use-case, inspired by JS and DOME: DOME has deprecated methods, Color.new(_,_,_) and Color.new(_,_,_,_). Like good deprecated methods, they print a warning. However, it can be hard to track the source, esp. if for example it's inside an external library you use. This would be a nice benefit if they would print the stack trace. In JS (although non-standard) developers usually create a new Error and print its stack property:
var Color = :{
  new(r, g, b) {
    console.log('Color.new(_,_,_) is deprecated. Please use Color.rgb(_,_,_) instead.');
    console.log(new Error().stack);
    // ...
  },
};

If we have the stackTrace property, we could copy this idiom to Wren:
class Color {
  construct new(r, g, b) {
    System.print("Color.new(_,_,_) is deprecated. Please use Color.rgb(_,_,_) instead.")
    System.print(Fiber.new().stackTrace);
    // ...
  }
}

This raise an interesting question/problem. Since we can get the current
fiber, we can get the current stack trace doing Fiber.current.stackTrace.
But the implementation I proposed does not have a stabilised output since
the thread is in flight. There are ways to solve this issue, but it does
requires to have access to the stack frame count to ignore anything after
(including) the call to stackTrace.

@mhermier I haven't reviewed your implementation in-depth, just took a glance, so sorry if this is a noob question: why doesn't it allow getting the stack trace of the current fiber?

It is not that it doesn't allow, the problem is that iterator stack is not
stable. While it is not truly a problem in practice with the
implementation, it will expose the fact that stackTrace is a function
call.

And to make things a little bit problematic, the behavior depends if it the
active Fiber or a stale one.

My current implementation seems to handles this case just fine.

I'm not sure about the implications of your proposed implementations.

Anyone know the status of this?  Really need it for test runners...  Some errors are impossible to debug without a working stack trace with a line number (such as method doesn't existing on null, etc)...  Right now I'm considering having to wrap each individual test inside it's own shell process just to get a stack trace (when the VM/CLI dies)... workable I think, but far from optimal.

I still have the patch on my branch, but I'm not really happy how it turns out. Thinking at it today, maybe it should be part of the mirror API with a FiberMirror.

The workaround I'm using for now for test library:
        if (first_error) {
            var test = _tests[first_error]
            System.print("--- TEST ---\n%(test.name)")
            System.print("--- STACKTRACE ---")
            Stdout.flush()
            Fiber.new(test.fn).call()

So after the entire test suite runs (and shows it's pretty output) I re-run the first failing test without try... this of course crashes the CLI and you only get a stack trace of a single test, but it's a start.

Please give a try with https://github.com/mhermier/wren/commits/mirror the API is far from final, and it was only ported from my original implementation (and I did not test it at all yet). But At least it should gives you ideas to help me with the API. And one good thing is that since we are outside of core, so we can add as many class as needed.

https://github.com/mhermier/wren/commit/3420b1fbe9fe6c9ede3d58162727a888247704a0 looks super awesome and total workable. I skimmed thru the whole commit.
Once we sort out the binary library API would you be willing to perhaps move Mirror into essentials or release it as an entirely separately binary library module?
Right now my proof of concept is based on a method lookup table (same as how modules are setup in the CLI), not a resolver function - well, the resolver function is just a loop around the lookup table... so when a binary library is loaded the new lookup class/method table is registered to the module list (so foreign methods can be found). But I imagine if need be we could also just make it possible for a library to export a WrenForeignMethodFn bindBuiltInForeignMethod(...) function to make it easier for someone to port from optional to a library (or maintain both).

Because it touch wren internals, I don't think it is feasible to make it something else than an optional/builtin library.
As this it was meant to reduce the impact in terms of class for core, but since it no longer the case, maybe we can make Fiber.stackTrace output a StackTrace object that is an instant image of when it was created, and allow fancier access/interaction and interact with the mirror API, by having MethodMirror...

Because it touches wren internals, I don't think it is feasible to make it something else than an optional/builtin library.

Can you give me one example of something particular you think wouldn't be possible?
Binary libraries have their own C code and can fully interact with Wren internals.  You'd have the same full access to the VM object and all Wren functions, etc...  I imagine once would need to build both Wren and the library at the same version number (duh), but other than that I'm not sure why it wouldn't just work.

Well to put it simple the wren API, don't offer any kind of introspection or access to Fiber and therefore its content. It can be solved by expanding Fiber in wren code with new symbols (which will hardly get reused) but this would pollute core. So for now it is not possible, without accessing internals via an optional module.

Well to put it simple the wren API, don't offer any kind of introspection or access to Fiber and therefore its content.

It doesn't need to.  Binary modules are  just C + Wren code. From the C side they have full access and introspection of all Wren internals.  Unless you added internals (in some other commit) I don't see anything in 3420b1f that looks like it wouldn't work just as well as a binary library.   If you're just using existing internals, no problem.

Now perhaps you're saying binary modules shouldn't have access to Wren internals, public API, private API, yada yada - that would be an entirely different point... to me though it's just C code.  You're using private API one way or the other.  To me where you put the code doesn't really change that.  I think the convenience of just installing a binary Mirror module by copying a single file vs having to recompile the Core language is a huge win for many use cases.
I'd think a "Compatible with Wren 0.4.0, uses private APIs.", etc. disclaimer is more than sufficient.

Well I think mirror should be part of wren library since it is very tight with the version of wren. And it has more sense to be there than random which can be completely done as a user module. That said the same licence apply, so if you want to take it, you are free to do so according to the license. So if it get rejected, I would recycle it for my personal use (part of the reason I have more than 250 patches), and you'll be free to maintain a copy of it, and I might contribute to it at some point.

Well I think mirror should be part of wren library since it is very tight with the version of wren. And it has more sense to be there than random which can be completely done as a user module.

Completely agree.  If Mirror was merged into Core (as an optional) then the CLI can just be built with ENABLE_MIRROR, and we get it "for free".  That'd be great.  So I'm specifically speaking of a potential future where it could be rejected - and forced to either live as a patch or a binary module.

I have more than 250 patches)

What I wonder (long-term) is how many of those could potentially be stand-alone libraries rather than patches against Core and if that wouldn't make it far more likely for others to see and use all your hard work rather than limiting it to people who are comfortable patching and recompiling Core.

you'll be free to maintain a copy of it, and I might contribute to it at some point.

Oh sure, of course.  Just (long-term) I want to avoid doing double work.  Perhaps it's more helpful to think of "binary libraries" as "optional modules that live outside the wren source tree"... that's the idea.  Adding optional modules without recompiling Core.
But it should be easy to go the other direction also.  Someone should be able to checkout Wren into one folder, and 5 binary libraries into other folders, and with only changing a few lines of code build a single executable with "batteries included".  It's all the same thing, the only differences is whether those libraries live in 5 separate files, or in a single larger binary.

I have more than 250 patches)

What I wonder (long-term) is how many of those could potentially be stand-alone libraries rather than patches against Core and if that wouldn't make it far more likely for others to see and use all your hard work rather than limiting it to people who are comfortable patching and recompiling Core.
Perhaps many of your patches change internals though, I dunno...

Most of them are  internal changes, rejected extensions to the languages, previous attempts of some of the features that now have a more proper pull request.
All in all, most of it is core extensions attempts (ByteArray, Char and some I don't particularly remember), and the previous attempt of the mirror API. The highest layers are attempts at solving the reentracy issue and the also an attempt at making an additional C++ version of the library (which would be almost header only).

Oh sure, of course. Just (long-term) I want to avoid doing double work. Perhaps it's more helpful to think of "binary libraries" as "optional modules that live outside the wren source tree"... that's the idea. Adding optional modules without recompiling Core.
But it should be easy to go the other direction also. Someone should be able to checkout Wren into one folder, and 5 binary libraries into other folders, and with only changing a few lines of code build a single executable with "batteries included". It's all the same thing, the only differences is whether those libraries live in 5 separate files, or in a single larger binary.

Well for me the modules is an unsolved problem, I find the builtin handling to be too much simplistic, and we should improve util/wren_to_c_string.py to a more advanced builtin resource generator with plugin stub/skeleton support, binary file support...

more advanced builtin resource generator ... plugin stub/skeleton support

I'm not 100% sure what you mean here, perhaps you'd want to join the discussion over on https://github.com/wren-lang/wren-cli/issues/52 and flesh out those ideas a bit.

we should improve util/wren_to_c_string.py

I've improved it slightly in essentials but to me tooling is almost secondary.  Once we have an official binary API for dynamic loading of binary modules then we can go crazy building out the tooling to make generating those dynamic libraries much simpler.  I'm not sure Wren Core is interested in these things (or if they even make sense), so mostly when I speak of these things I'm talking about Wren CLI.
Writing clean C code isn't my strong suit though so I'm hoping someone comes along interested in that piece of the puzzle.  The branch I pointed you to earlier works 100%.  You can compile essentials as a stand-alone dynamic library and then import it an runtime... it all "just works", but the paths are still hard-coded, etc...

I mean some infrastructure/tooling to normalize external plugin loading.
I don't blame you in particular, but I think that the fork culture is plaguing wren. essentials and other solutions is not the solution for me. We lack a community page of maintained projects/libraries/resources, and contributions from the community (even if it improved a little recently).

I mean some infrastructure/tooling to normalize external plugin loading.

That's what wren-lang/wren-cli#52  is working towards.  It of course ultimately needs more testing, polish, and merging into CLI proper.

I don't blame you in particular, but I think that the fork culture is plaguing wren. essentials and other solutions is not the solution for me.

Not sure I follow.  This is what I'm trying to avoid - everyone having to maintain 100 patches just for binary libraries.  essentials is just a binary library, it's not a fork of anything.  In the future you'd hopefully just type wrenlib install essentials or wrenlib install json.  Just like you might type gem install json in Ruby.
And then the library would be installed locally and ready to use for any script.

@joshgoebel Well from my understanding it, essential is a deviation based on taste/jugement. Considering the amount of possible patch maintenance work, maintaining a distribution of wren where patches would be controlled by macro configuration is not a viable solution until code stabilize for good. So I think, for now, it would be better to have a maintained list of feature branches containing only one or the fewest possible features.

@joshgoebel Well from my understanding it, essential is a deviation based on taste/judgement.

A deviation from what?  It's just a library.  It would be Wren + C code that is 100% compatible with Wren Core (with zero patches).  It seems very natural to me to group related functionality into modules/classes (as every other languages I know does). Some sort of "one function per branch" seems very strange (for libraries) - and also a huge amount of work vs just publishing a library - as is already common practice: https://github.com/wren-lang/wren/wiki/Modules.
I totally see where that makes sense for patchsets, but not libraries.

Considering the amount of possible patch maintenance work, maintaining a distribution of wren where patches would be controlled by macro configuration is not a viable solution until code stabilize for good.

I don't really have a great answer for "patches" to Wren Core... that's entirely outside the scope of what I'm working on and I think a different (but related) problem entirely...

@mhermier Trying to get this FiberMirror stuff to work without success.    I get an error with the stack trace builder:
Fn does not implement 'module'.

_stackTrace.add("at %( fn.module.name ):%( fn.name ) line %( line )")

module isn't a documented getter for Fn... am I missing something?

Related to a patch of mine that expose modules as objects. Will think of a way to deal with that, probably using mirrors.
If you have test cases to submit, it would help me a lot.

If you have test cases to submit, it would help me a lot.

No, but it all seems to work other than one tiny typo and missing Fn.module and Fn#name.  I was porting Mirror to an external binary library just to show how it's done. :-)

probably using mirrors.

That was my thought, a FunctionMirror.

Related to a patch of mine that expose modules as objects.

Link to commit?  I wasn't seeing the code.

For now it will stay private. The modules are not exposed by design, and I don't want to raise more controversies for now. There is already some raging debates to fight that this one. I'll try to make it using mirrors, even if it leaks modules objects, but don't extends a class for them. (It means reflected will return a value with a null type).

For now it will stay private. The modules are not exposed by design, and I don't want to raise more controversies for now. There is already some raging debates to fight that this one.

Hmmmm... Why is saying expose them as objects? But you have to expose "function name" and "module name" to have a workable stack trace - there is no way around that. So do some simply think you shouldn't be able to get a stack trace of a failing fiber?
I was imagining that you'd add:
class FunctionMirror {
  foreign name { ... }
  foreign moduleName { ... }
}

Just the bare minimum needed for stack tracing.

Things are taking shape :
at ./scratch: null line 54
at mirror: null line 70

Still have some issues:

how MethodMirror should be addressed
probably an issue with line numbers
reverse stack printing ordering ?

Maybe we could coordinate a bit on Discord?  I'm starting to think I may need this sooner rather than later and perhaps there is some way I could help.  My context/use case is teaching others to program in Wren via programming exercises and I'm finding it really hard to work thru failing tests without a proper stack trace pointing to the line that has actually caused the error.  So much so that it might actually be a blocker for my use case.

I don't use discord, and will not subscribe. I have a personal rule of diminishing as much as possible my internet finger print, in terms of social media/chat group/... so I only maintain what I already have, unless absolutely required. Don't know if you can send me private message on github ?
The prototype is working to some extent, thought I have a memory optimization to look before I'll push a new version for test. It seems that a function/method object is storing its name as a plain C string, and it would be more efficient to use an ObjString since we have it already in the symbol table. So I have to look what is really going on.

Don't know if you can send me private message on github ?

Not that I know of. :)  Signal?

a memory optimization to look before I'll push a new version for test.

Very curious to see what you come up with and how low-level it is.  I'm still hoping to migrate the Mirror stuff to a library so it can be loaded dynamically.  I was 95% there before I ran into the missing access to module/function name. :)

No Signal XD
I pushed an update, I did not included the change for debug->name. While it should reduce memory usage, it didn't resulted in enough improvements for now.

Are you sure it shouldn't be:
for (i in 0...stackFramesCount) {

With 3 dots?

Haven't diagnosed it yet but it also seems to get "stuck" inside classes...
at ./test: new(_) block argument line 18
at ./test: new(_) block argument line 11
at ./test: new(_) block argument line 10
at ./test: new(_) block argument line 9
at ./test: smith() line 14

import "essentials:essentials" for Strings
import "mirror" for Mirror

System.print(Strings.upcase("bob"))
System.print(Strings.downcase("LUCY"))

var e = Fn.new { Fiber.abort("bad") }
var d = Fn.new { e.call(22) }
var c = Fn.new { Boo.smith() }
var b= Fn.new { c.call(96)}
var a = Fn.new { b.call(32) }

class Boo {
    static smith() { d.call() }
}

var f = Fiber.new(Fn.new {
    a.call()
})

var x = f.try()
System.print(Mirror.reflect(f).stackTrace)
System.print("STILL RUNNING")

The stack trace just stops inside smith() when it should continue into the two other anonymous functions.

Can be ... I usually don't use raw loops. But the output doesn't seems correct, I wanted to have the stackTrace call on Fiber.current
I was not able to reproduce where you are stuck.

My fault.  I was only printing the trace, not the error.  I needed D not d so it could find the method.  It works now:
at ./test: new(_) block argument line 18
at ./test: new(_) block argument line 11
at ./test: new(_) block argument line 10
at ./test: new(_) block argument line 9
at ./test: smith() line 14
at ./test: new(_) block argument line 8
at ./test: new(_) block argument line 7
STILL RUNNING

The new(_) for anonymous functions is just a limitation we're stuck with you think?

I wanted to have the stackTrace call on Fiber.current

I'l call it from the "main" thread but wanting the trace of the fiber that crashed.  It seems to work perfectly now that I fixed the error in the code. :) (with the ... fix)

I think it is a limitation of the compiler when it creates the function. For now I'm looking for functional bug, this one is more cosmetic.

Porting into a library:

We need a module registry to export vs a function https://github.com/joshgoebel/wren-essentials/commit/8ed56e41ea256bc31ca816cb83eee62c97a97a67#diff-bed23027c3ffe20e5cec93de0d8453bb70bb73bcc79981289f4c87e5ed769625R31
We have to pull over a few things from Wren (that aren't exposed) https://github.com/joshgoebel/wren-essentials/commit/8ed56e41ea256bc31ca816cb83eee62c97a97a67#diff-7a77f1faae3f857b93348b56293069f98edfa75ba0b647e2ab7cf5bb87d7821fR6 (probably should live in a sep file long-term)
The .wren code is compiled into large C string blobs and referenced in the module registry, just the same as it's done in the CLI modules. It's loaded via the same loadModules code in the CLI that's been altered to be binary library aware.

BUT... if you're using the latest wren-essentials and my binary-libs branch you can now compile libwren_essentials.dylib and then load it into the CLI at runtime.  And boom, access to stack traces via the mirror module.
So yes, it does require access to a few "wren internals" but that doesn't mean that access can't be provided at a later date via a binary extension library - it doesn't have to be compiled into the CLI from the very beginning.  Just as long as you're using the same data structures, etc....  I think libraries that do this should be very careful to say so and make it clear they depend on Wren internals.  Definitely not a thing every library needs to do.

Updated, I made Stacktrace a Sequenceable thought it is not yet Indexable.

Updated, I made Stacktrace a Sequenceable thought it is not yet Indexable.

Very difficult to keep up with your rebasing. :-) That's why we need something automated. :)

Because it was not meant to be taken but reviewed.

Thanks for all your hard work on this, really do appreciate it.

Because it was not meant to be taken but reviewed.

Even for just reviewing I find it easier to keep up with moving changes to a PR when I can see the individual commits as they layer on.  Perhaps it's just me.

Even for just reviewing I find it easier to keep up with moving changes to a PR when I can see the individual commits as they layer on. Perhaps it's just me.

It is not just you, but a way of mine to deal with patches and propositions. I have changes that impact so much the code, that it is almost impossible to do a merge each time an update it is performed.
In addition I consider most of the patch, I issue for pull requests as "for the eyes/test only" until it was discussed, agreed. This is so I can fix patch sets, and don't have patch of patch of patch, that are impossible to revert or simply read.

You can have your cake and eat it too if you interactively rebase.  It's all about how you lay out the commits so when you rebase at the very end you can squash them down into the structure you desired all along... so while committing/developing, you have the FULL history on top (and for reviewers it's easy to see what you JUST changed), yet at the end you still have only 3 clean commits. (and they merge or patch as easily as they do now)
Git is pretty amazing like that.

Yes but usually the bus factor is so long that I have to reduce the patch set often so I don't loose track of what is going on, multiplied by the number of changes that I have in flight...


Database requirements

Hi Antoine,
I like your chat application, very interesting implementation in vue.js. Which database do you suggest I can use on the backend for this application?
Thanks,
Kashyap

You can use firebase as there is a built-in implementation in the demo project.
Otherwise there is no recommandation, you can use any backend you want.


Using Volumes instead of Mount

Thank you for the good documentation.
I used a mongodb instead of the sql server and it worked well using mount.
As the docker documentation mentions to use volumes instead of mounts, i wondered how the syntax would work on this one.
I tried to use:
{
"HostConfig": {
"PortBindings": {
"27017/tcp": [
{
"HostPort": "27017"
}
]
}
},
"ExposedPorts": {
"27017/tcp": {}
},
"Config": {
"Volumes": {
"/data/configdb": "mongoconfig",
"/data/db": "mongodb"
}
}
}

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9f033d3a-7af4-53ce-e7da-4ac7444520ce
Version Independent ID: 1f2f6875-6f69-83f7-1181-ea3e01946813
Content: Tutorial store data with SQL module - Azure IoT Edge
Content Source: articles/iot-edge/tutorial-store-data-sql-server.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

Hi @usermartin thanks for the kudos! As this falls out of the context of this doc, can I kindly request that you ask the same on Stack Overflow so we can leverage the expertise of the community there? Let us know the link when you do so.
Thank you!

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Fix the links that tries to point to top-level Contributing section.

To:
@udemy/team-f
What:
Fixes the relative links to top-level Contributing section.
Trello:
Part of https://trello.com/c/CGOZCMkS/1706-re-organize-all-eslint-udemy-repos
What did you test:
The links themselves.
What dashboards will you be monitoring:
None

 Re-organize all eslint-udemy-* repos.


Topic Support?

It appears that GitHub may have added Topics support via the API:
https://developer.github.com/v3/
It is currently a preview, and requires the following Accept header to be set: application/vnd.github.mercy-preview+json.
This would be a useful command to add, but would like to hold off until #30 is complete.

Implemented in #51


fix(deps): update module golang.org/x/crypto to v0.16.0

This PR contains the following updates:

Package
Type
Update
Change

golang.org/x/crypto
require
minor
v0.15.0 -> v0.16.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.25.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add serialisation format of ABIs into JSON

Related issue(s)
Serialisation logic relies on array lengths fitting in a u64 #525
Logic being format used to serialise ABI described in #524
Closes #524
Description
Summary of changes
This PR adds logic to serialise/deserialise circuit ABIs so it can be saved to a JSON file and used elsewhere.
The Abi struct is not suitable for serialising directly (see #524 and #525) so we convert it to an intermediary format and then serialise this instead (this allows us to use the derived serde implementations rather than making the modifications inside a custom implementation).
Storing the ABI in JSON is useful as it makes generating/verifying proofs from TS much more robust. Currently TS users don't get any typechecking on their inputs  to proving/verifying which means they get arcane wasm errors should they update their circuit and forget to update their TS code to match. With this however, we could automatically generate TS bindings for Noir circuits ("typechain for noir") which would avoid these issues.
More generally, this is very useful anywhere you need to generate/verify proofs without having access to the noir source code.
The generation of Prover.toml/Verifier.toml template files was piggybacking on the Deserialize trait so I had to create a new function to create those.
Dependency additions / changes
Added serde_json as a dev dependency to noirc_abi for a test
Test additions / changes
Added a test that we can successfully deserialise a JSON representation of an ABI.
Checklist

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt with default settings.
[x] I have linked this PR to the issue(s) that it resolves.
[x] I have reviewed the changes on GitHub, line by line.
[x] I have ensured all changes are covered in the description.

Additional context
(If applicable.)

I'm not sure I follow. Even if we say that we're going to receive input from the user as a flattened array of field elements, we still need to expose information on how they should generate that set of field elements.
Let's say I'm running a server which users can send the circuit arguments to and I will generate a proof for them on this circuit, and to do this they need to provide the arguments encoded as an array of field elements. We now need some client-side code which will take structured inputs and flatten it down into this array, otherwise how will the user know the correct order for the arguments, etc?
We could just allow this function to take any input and attempt to flatten it but then we run into potential troubles with misordering of parameters, missing inputs, etc. as mentioned in #524. The client doesn't know that its encoding data incorrectly so the issue will only arise once my server has received the input and is attempting to prove it. To avoid this, we need to tell the client what format of data I'm expecting it to send me in a flattened form.
I can't just send the client the source code and tell it to compute the ABI itself as it's running in the browser so it'll be hard to run nargo on it. It's also unlikely that my server will even store the source code itself as opposed to just the circuit + ABI, realistically I'd compile the program locally and upload the build outputs to avoid bloat.

I thought you wanted to serialise the witness... my bad!
In fact this is not about the values but about the types only, which we need to serialize, because we also serialize the circuit, I do agree with this.
However there were already a serialize method, which if I understand now correctly does not work because of this u128 thing.
You are fixing this by creating an intermediate type which uses u64 instead of the u128 and I don't think it is the proper way to fix this, because indirectly this means we cannot have arrays with u128 length as it will crash if we do.
So either we are able to serialise u128 values or we change the ABI to use u64 directly, not inside an intermediate type.
Note that since we can use integers nearly up to u128 in noir, we should be able to serialize u128 values in any cases.

I'd support lowering array sizes to u64 in general as well. There's no real reason to support array sizes between u64::MAX and u128::MAX. If you're using an application that needs array sizes that big, it's more likely you actually need arbitrary array sizes over u128::MAX as well.

However there were already a serialize method, which if I understand now correctly does not work because of this u128 thing. You are fixing this by creating an intermediate type which uses u64 instead of the u128.

Yes and no, I guess. The current serialize method doesn't create a valid representation of an Abi which could be reversed by the generated deserialize method. If we removed the current serialize method and used the codegened one, then this would be broken by the u128 issue.
That's not the main reasoning behind the intermediate type however. Most of the changes are to ensure that ordering of the fields is maintained through a round of serialization and to make it easier to manipulate for programs which are just using it to validate arguments (I listed these in more detail in #524).
I agree that the mismatch between the accepted types in AbiType and Type aren't a long term solution however I wanted to avoid making changes to the inner workings of the compiler. Depending on how we resolve #525 we can either propagate out the changes to u64 or add a custom serializer for u128 values (however this would have a knock-on effect on any users of the ABI requiring this as well).

We should go for the long term solution and fix #525. I don't really mind if we change the array length to u64 or implement a custom u128 serialiser (because we need it anyway), but since Jake is in favor of the former, I suggest to change to u64.
I don't expect this to be a major change in the inner working of the compiler, let me know if I am wrong and it requires to modify stuff you are not comfortable with.

@TomAFrench this was failing CI since we last touched base, is there anything blocking you on it?

Hey @kevaundray, no blockers on my side. I've had a few things crop up which ate up a lot of my spare time so haven't been able to revisit this before.

Should be good now, the remaining issues will be fixed with #592

Thank you very much @TomAFrench , I've re-requested Guillaume to give this a once over, then we can merge :)

I agree to have the visibility only in the AbiParameter (and be it not optional here!), and not inside the AbiType, where it does not make sense (what means pub a : struct{ b:Field, pub c:Field}? or (private)a : struct{ b:Field, pub c:Field}?).
For the second issue, I am ok with using a Vec (but I wonder why rust can't just serialise a BTreeMap..)

(and be it not optional here!)

This was only to avoid creating yet another new struct to handle struct fields. To be clear, these structs are just glorified helpers for serde to derive the correct (de-)serialiser and wouldn't be used elsewhere so correctness is enforced by Abi and AbiType still. As AbiParameter is being adopted as part of Abi now, we should have specific logic for struct fields now.

For the second issue, I am ok with using a Vec (but I wonder why rust can't just serialise a BTreeMap..)

This is described in #524. This is an issue that won't pop up in Rust but could be very annoying in other languages. The reason for this is that BTreeMap has a well defined ordering for its keys.
This means that the Noir structs
struct orderedStruct {
  a: Field,
  b: Field,
  c: Field
}

struct misOrderedStruct {
  a: Field,
  c: Field,
  b: Field
}

are both represented as the array of witnesses [a_witness, b_witness, c_witness].
However the JSON spec doesn't define a ordering to maps so you could read this into Typescript (where objects/maps use insertion ordering for string keys) and the fields will be ordered in a potentially random order. This makes it much more difficult to perform ABI encoding in TS as on each struct you would have to know to manually check all of its field names and put them in order before continuing the encoding. If we represent structs as arrays in the JSON then it's much easier to go from the ABI to a vector of field elements without potentially transposing any of them.


Code quality fix - Methods named "equals" should override Object.equals(Object)

This pull request is focused on resolving occurrences of rule:
squid:S1201 - Methods named "equals" should override Object.equals(Object)
You can find more information about the issue here:
http://dev.eclipse.org/sonar/rules/show/squid:S1201
Please let me know if you have any questions.
Faisal

@mrniko  Thanks. What about following PRs?
https://github.com/mrniko/netty-socketio/pull/292
https://github.com/mrniko/netty-socketio/pull/291


Text module remains untested.

Add tests to text module.

All dpyp.text functions now have rudimentary unit testing.


Symfony 2.8?

Hi,
I'm planning on using this Symfony edition but wondered if I could use it with version 2.8?
Would changing the dependency cause compatibility issues?
Many thanks.

PR closed https://github.com/gimler/symfony-rest-edition/pull/59


Bash script should find writeable location

Currently, bash script links (ending in .sh), try and temporarily write the file in whatever directory it is run.
However, often when popping web RCE, the invoking user doesn't have permission to write in the current directory.
It would be cool if the script were to first try other folders like /tmp, /dev/shm, etc, before resorting to writing in the current directory.
Thank :)

Huh, I was of the impression that if the script could be written to the current directory, it would also be able to write the binary. I'll have a look into this.
My only concern, is that people often set noexec on /tmp

I've added a commit for this on unstable branch. Feel free to try it out


Get names of Days

Hi.
There is some way of verifying the name of the day?
I would like to be able to deactivate or to activate days dynamically. For example, to deactivate every day that they are not Thursday
Thanks!!!

In which context, Do you mean showing the days?  If this is the case its a feature request.


Output Node names

I am trying to convert your model into .dlc format which is Qualcomm Snapdragon (SNPE) format.
I gave the output node names "pred_sbbox/concat_2, pred_mbbox/concat_2, pred_lbbox/concat_2"
However its says that ERROR_TF_NODE_NOT_FOUND_IN_GRAPH: Node not found in graph. Node name: pred_sbbox/concat_2
Kindly let me know the whats the output node names.

I met the same problem, I found that SNPE seems not support leaky relu in Tensorflow.
Now I replace the leakyRelu operation with relu.

hi @Rahn80643, @sainisanjay
I'm trying to convert yolov3 pb file to dlc, and have similar problem,
after I replace leakyRelu to Relu, another problem happened, the error message showed below:
"ERROR - Conversion failed: build_layer failed with Exception ERROR_TF_LAYER_INPUT_COUNT_ERROR: Layer Convolution expects 1 input(s), actual 2 in layer ResizeLayerBuilder"
Did you know how to solves this? Or both of you have already convert dlc file successfully?
Any suggestion will be appreciated. Thanks

Same problem, any news?

I met the same problem, I found that SNPE seems not support leaky relu in Tensorflow.
Now I replace the leakyRelu operation with relu.

Hi buddy,
Have you resolved this issue?


Cat api

Codecov Report

Merging #74 (b1f7fda) into master (1d0fbfa) will decrease coverage by 12.55%.
The diff coverage is 69.66%.

@@             Coverage Diff             @@
##           master      #74       +/-   ##
===========================================
- Coverage   80.98%   68.42%   -12.56%
===========================================
  Files          51       51
  Lines        5112     5147       +35
  Branches      616      616
===========================================
- Hits         4140     3522      -618
- Misses        735     1438      +703
+ Partials      237      187       -50

Impacted Files
Coverage Δ

...otlin/dev/evo/elasticmagic/ElasticsearchCluster.kt
0.85% <0.00%> (-90.60%)
:arrow_down:

...otlin/dev/evo/elasticmagic/compile/BulkCompiler.kt
0.00% <0.00%> (-90.91%)
:arrow_down:

...ev/evo/elasticmagic/compile/CreateIndexCompiler.kt
0.00% <0.00%> (-81.40%)
:arrow_down:

.../evo/elasticmagic/compile/UpdateMappingCompiler.kt
0.00% <0.00%> (-96.67%)
:arrow_down:

...monMain/kotlin/dev/evo/elasticmagic/query/Match.kt
93.50% <ø> (ø)

...ain/kotlin/dev/evo/elasticmagic/types/FieldType.kt
74.21% <ø> (-5.23%)
:arrow_down:

...ev/evo/elasticmagic/compile/SearchQueryCompiler.kt
51.05% <50.00%> (-44.22%)
:arrow_down:

...o/elasticmagic/transport/ElasticsearchTransport.kt
73.27% <85.07%> (-2.59%)
:arrow_down:

...tlin/dev/evo/elasticmagic/serde/StdDeserializer.kt
38.38% <100.00%> (-13.66%)
:arrow_down:

...monMain/kotlin/dev/evo/elasticmagic/aggs/Metric.kt
86.26% <100.00%> (+0.05%)
:arrow_up:

... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d0fbfa...b1f7fda. Read the comment docs.


Allow Queries with no Auth

If I don't specify the auth token, it still sends an "Authorization" header, which the server sees as incorrect syntax.

Good day, In order to solve the problem I need additional information.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Set up environment
Arguments
Function/method
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment

Repository
OS: [e.g. Win/Mac/Linux]
IDE [e.g. REPL, Jupyter lab/notebook, Aton/Juno, Visual Studio Code]
Project/Manifest

Additional context
Add any other context about the problem here.


[WIP] Update Meshery results to follow SMP

Description
This PR fixes #896 | This is in WIP
I was able to refactor the results in the YAML file but I'm stuck in getting the other missing results. I'm also not sure what those values mean and how I can access them...

[ ] Yes, I signed my commits.

This is good. I should clarify that not all values have been implemented and so only a subset are available for export. This might be all that is available currently.
We need to work toward implementing the rest. We might want to merge this work as a step forward in the meantime.

@leecalcote Yes, I have been trying to figure out where to pick these values from... There are some missing values here but this result follows SMP and only the rest of the values need to be filled...

@leecalcote Yes, I have been trying to figure out where to pick these values from... There are some missing values here but this result follows SMP and only the rest of the values need to be filled...

@leecalcote I have resolved the merge conflicts...


Not working with RN v0.62.0

This package in not working with RN v0.62.0. It's not getting linked in native dirs

I Just link it (react-native link) , after this I clean gradle : cd android; ./gradlew clean  and this work

yeah, i spent like 6 hours today trying to get this library to work. RN 0.62 i tried all three of the ios options. none seem to work. idk what to do.

I Just link it (react-native link) , after this I clean gradle : cd android; ./gradlew clean  and this work

Not working

I found solution, make sure that the fonts are on the right path, by linking to 0.62, he created a src on the root of android, right path, android\app\src\main

I found solution, make sure that the fonts are on the right path, by linking to 0.62, he created a src on the root of android, right path, android\app\src\main

I think the issue is with v0.62.0 itself and not with this package. I e opened an issue on react-native repo https://github.com/facebook/react-native/issues/28430. Everyone facing issue and comment there.

it works for me by Manual linking
of course with skipping 'Edit your MainApplication.java... ' step

Any solution? I tried react-native link and still doesn't work.

If your found this error Red screen with "Unrecognized font family" error, try this.
put this
<key>UIAppFonts</key>
	<array>
			<string>AntDesign.ttf</string>
			<string>Entypo.ttf</string>
			<string>EvilIcons.ttf</string>
			<string>Feather.ttf</string>
			<string>FontAwesome.ttf</string>
			<string>FontAwesome5_Brands.ttf</string>
			<string>FontAwesome5_Regular.ttf</string>
			<string>FontAwesome5_Solid.ttf</string>
			<string>Foundation.ttf</string>
			<string>Ionicons.ttf</string>
			<string>MaterialIcons.ttf</string>
			<string>MaterialCommunityIcons.ttf</string>
			<string>SimpleLineIcons.ttf</string>
			<string>Octicons.ttf</string>
			<string>Zocial.ttf</string>
	</array>

at the end in Info.plist. It works for me react-native: 0.62.1

If your found this error Red screen with "Unrecognized font family" error, try this.
put this
<key>UIAppFonts</key>
	<array>
			<string>AntDesign.ttf</string>
			<string>Entypo.ttf</string>
			<string>EvilIcons.ttf</string>
			<string>Feather.ttf</string>
			<string>FontAwesome.ttf</string>
			<string>FontAwesome5_Brands.ttf</string>
			<string>FontAwesome5_Regular.ttf</string>
			<string>FontAwesome5_Solid.ttf</string>
			<string>Foundation.ttf</string>
			<string>Ionicons.ttf</string>
			<string>MaterialIcons.ttf</string>
			<string>MaterialCommunityIcons.ttf</string>
			<string>SimpleLineIcons.ttf</string>
			<string>Octicons.ttf</string>
			<string>Zocial.ttf</string>
	</array>

at the end in Info.plist. It works for me react-native: 0.62.1

This solves my problem. Thanks!

Not working in RN 62.1  Tried everything.

You also need to add the fonts as assets:
react-native.config.js:
module.exports = {
  assets: ['./assets/fonts/'],
};

Add the font(s) to said folder:

(Not sure if required but maybe do it anyway): cd ios && pod install
Example test case (I don't know where to find all the type names, some guessing required):
  <Input
     label="Phone number"
     placeholder="555 5555"
     leftIcon={
        <Icon name="phone" type="simple-line-icon" color="#517fa4" />
     }
     value={phoneNumber}
     errorStyle={{color: 'red'}}
     errorMessage="ENTER A VALID ERROR HERE"
  />

Clean the build folder and start up your project again:

suggestion from @allpwrfulroot worked.
So, here's the rundown on what finally got this working for me in RN v0.62.1.  I am also using react-native-elements, which has a dependency on react-native-vector-icons, so this fix was extremely important.
yarn add react-native-vector-icons
Android:

Follow the instructions on the react-native-vector-icons page under the heading "Option: With Gradle (recommended)"
Add react-native.config.js to your project as described above
Copy the .ttf files into the new assets/fonts/ directory in your project as described above
I ran cd android && ./gradlew clean but that may not be necessary

iOS:

Updated the Info.plist file with all of the fonts files I want as described above
I did not need to copy the font files into Xcode as described in the instructions.
I ran cd ios && pod install

Thank you!

For anyone using npx react-native run-ios,  you have to use it like:
import Icon from "react-native-vector-icons/Feather";

Icon.loadFont();

I use manual linking as described in the readme
https://github.com/oblador/react-native-vector-icons#android
So, I do not need to specifying anything related to vector-icons in react-native.config.js.
This all works with RN 0.62.
The only blocking issue to migrate to 0.62, is https://github.com/oblador/react-native-vector-icons/pull/1153  (and it is because 6.6.1 release with ToolbarAndroid fix is not published to npm)

@nbcnc detailed step-by-step, based on @allpwrfulroot answer worked for me. Guys, you saved my day! Thank you!!!

Isn' @allpwrfulroot 's solution just manually copying the fonts to the local RN project and not linking it anyway to the node_modules?


The commands are available in the Source Control view and the Command Palette when a Git repository is open.
(This commit was generated by the new Cody command 😍 )
TBD

[ ] Should we keep generating commit without including the ignored items? Current behavior is to display the error in the input box to let user know that there is an ignored file included.
[ ] If there is no staged files, should we still generate commit for unstaged files?

Test plan

New feature covered by a new e2e test.
Manual Tests
From the Cody Commands sidebar

Start Cody in dev mode from this branch
Make some changes in your editor, and leave them unstaged
Click on the Generate Commit in the Cody Commands sidebar
You should be redirected to the Source Control sidebar
The Source Control panel will be focused, and Cody's response will start streaming into the input box directly
Verify Cody's response

From the Source Control sidebar

Start Cody in dev mode from this branch
Make some changes in your editor, and leave them unstaged
Open the Source Control sidebar, and make sure the commit input is empty
Hover over the commit input box to see Cody icon shows up in the title bar
Click on the Cody icon in the title bar
Cody's response will start streaming into the input box directly
Verify Cody's response

When an ignored file is detected

Start Cody in dev mode from this branch
Make changes in a Cody ignored file
Click on the Generate Commit in the Cody Commands sidebaror Cody icon in the Source Control  panel.
You should be redirected to the Source Control sidebar
The Source Control panel will be focused
An error message will show up about the ignored file

Also, idea: We should use the typewriter lib/shared/src/chat/typewriter.ts to make the streaming of the text into the input box more fluid

I think let's merge the function and then iterate on the response quality. We can then also add a few different prompts and some metrics on which one's gets comitted as suggested (or hamming distance?).

@RXminuS Sounds good, anything you want to add, or happy to merge this?

I still need to merge my e2e test fix I think because they don't pass yet right?

@RXminuS 👍 yep (only just noticed lol :D)


ui issue in category in calender icon  in mobile view

Bagisto Version

[ ] master branch

Steps To Reproduce

go to category section

Actual Result

Expected Result

@deepaksinghgusain227  @prateek-webkul
There is not any UI issue. Please find the screenshot Here


Add Educational Resources

Acceptance Criteria
GIVEN A developer/Contributor
WHEN Contributor visits this project's README
THEN They should see some resources they can use to learn/level up/refresh their Next JS and React knowledge so that they can easily contribute to this project
DEV NOTES

Update the project's README file to include resources a contributor can use to level up on this project's tech stack.
List the resource's title/name with the link to the resource. For example, if it is a YouTube video, list the YouTube video title and link it to the actual video itself.

DESIGN Notes

There are no mockups for this story. Please use markdown when editing the README

Can you assign this task to me?


test(ui): Temporarily disable flaky workload cve toolbar test

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #7039   👈

This comment was auto-generated by Graphite.


Java Billing proto update

billing.proto was updated in googleapis in this commit and the proto and grpc libraries need to be updated.
The version numbers are bumped to 0.1.20 accordingly.

I signed it!

PTAL.

My concern is addressed - @vam-google or @neozwu can do final approval.

PTAL.


PHP 5.4

Is there a special need for not supporting 5.4? google/apiclient is satisfied with >= 5.2.1 and laravel/framework >= 5.4.0..

There is no specific >= 5.4 functionality being used but 5.5 was set as a requirement with these posts in mind. But when looking at the currently supported versions I could indeed set 5.4 as a minmum until September.

If there is no specific code that needs a higher version, I would say it is a good idea to support the versions that are currently supported.
I totally agree on those blog posts but at the moment I'm having a 5.4 project and it won't be updated soon unfortunately.

Thanks for making the adjustment!


Started on responsive content

Before vs After
1920 width desktop

Ipad Landscape (1024 width)

Ipad (768 width)

Iphone (3xx width)

@mike-robertson I have added the screenshots.

put the row and column into TableContainer

That won't work. You need the Row outside of the container. Which means, if you do the Col in the container. They get messed up.

Pass xs sm md and lg props into TableContainer. Make default values 12 (so we don't have to pass them in to get max width).

It's not working. I think we can always do this later once we add these props to all the pages.

We still need to allow scrolling on tables if they get broken or have some other solution for tables with more than 3 small columns.

Yes, it needs to be done on table-by-table basis and is my next step. The common scroll behavior fucks up the width even though it has scroll. So, it wasn't exactly right beforehand.

Actually, I was originally correct. The change is super easy.
Go to Table.css (keep the changes you made though):

/*Override material-ui style*/
.innerContainer > div > div {
  overflow-y: hidden !important;
  overflow-x: auto !important;
}

Nope. You still the need the grid. The overflow is only about scrolling/

The grid is about the changes in this file.https://github.com/odota/ui/blob/995b00970939f1027aeab172af542d2806d25e15/src/components/Player/Pages/Counts/Counts.css

You don't need the grid. We just need to be smart with our css. Check out my PR for how that's possible. You may also want read up on flexbox, it's very powerful and doesn't require tons of media queries or grid libraries to be responsive.


Request recordings show when control is transferred into a thread by an ExecutorService

Currently, if an HTTP endpoint (e.g. a Spring Controller) uses an ExecutorService to do some processing, none of that processing shows up in the AppMap. So, for example:
    @GetMapping("parallel")
    public String parallel() throws ExecutionException, InterruptedException {
        ExecutorService executorService = Executors.newCachedThreadPool();
        Future<Object> future1 = executorService.submit((Callable<Object>) () -> new HelloWorld().hello("John"));
        Future<Object> future2 = executorService.submit((Callable<Object>) () -> new HelloWorld().hello("Paul"));

        return future1.get() + " " + future2.get();
    }

the calls to HelloWorld.hello will not get added to the AppMap.
Instead, the (pseudo) events should look like this:
{id: 1, http_server_request, thread: 1}
{id: 2, call: ExecuteService.submit, thread: 1}
{id: 3, call: HelloWorld.hello("John"), thread: 1}
{id: 4, return, parent: 3, thread: 1}
{id: 5, call: HelloWorld.hello("Paul"), thread: 1}
{id: 6, return, parent: 5, thread: 1}
{id: 7, return, parent: 2}
{id: 8, http_server_response, thread: 1}

So, they all have the same thread id, and the ordering of the call and return events show that the calls to hello originated from the call to submit. Note that the order they appear in the recording may not match the order in the code (because they're running on separate threads).
It's still TBD exactly what events will get added for calls to ExecutorService methods.

@apotterri Is this for the JetBrains plugin or for https://github.com/getappmap/appmap-java?

Oops, sorry.


Discussion: Bugs to be fixed in WinUI 3 Preview 2

Discussion: Bugs to be fixed in WinUI 3 Preview 2

Hi everyone!
Our team is hard at work on WinUI 3 Preview 2 and are excited to share it with you all as soon as possible. As we announced previously, Preview 2 will be a stability and quality focused release, with an emphasis on fixing bugs from Preview 1. In order to make sure that our work really focuses on our developers, I wanted to ask our community:
What are the serious and/or blocking bugs that you encountered in Preview 1?
As we work through bugs we want to make sure that we're fixing ones that will really impact your quality of life as a developer, so feel free to share any significant ones in the comments.
NOTE: Please "thumbs up" ones that you agree with/have also encountered! This makes it much easier for us to keep track.
Thanks!

Thorn on side: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Support for System.Collections.Specialized.INotifyCollectionChanged
It's quite involved to try and rewrite your app currently to make it work, and a lot of View Models rely on observable collections to function. I gave up trying to port any current applications to WinUI, simply because significant rewrites were required. It was by far the single most biggest blocker for trying to run any existing code on WinUI.

System.Collections.Specialized.INotifyCollectionChanged is the biggest one that hides all the rest

#2236

Back on March 25th, I posted this (regarding the Alpha release):
Windows UI should support at least the major MVVM frameworks- MVVM Light, Prism, and Caliburn. Unfortunately, your documented problem with changes to INotifyPropertyChanged and INotifyCollectionChanged breaking ObservableCollection certainly breaks MVVM Light, and probably the other two frameworks as well. Thought you should know.
(https://github.com/microsoft/microsoft-ui-xaml/issues/1045)
If the goal is 'one UI to bind them all', you need to maintain enough compatibility that developers aren't chasing some moving target you keep shifting. How many projects do you think uses these frameworks?

I'd also like to see you bring some love for WinRT back into Win UI.  The Win32 support is lovely, but where did WinRT go? And why?

@terrycox, what lack of WinRT love are you referring to?

The Alpha documentation contained procedures and templates for updating WinRT apps to use Win UI 3. All of that disappeared in Preview 1, which had templates for Win32 apps, but no templates for UWP progs, and no mention in the documentation whatsoever.
I understand that the focus was on the new bits, Win32, and that the code didn't vanish, but it was disconcerting to see WinRT references disappear altogether.

The documentation and templates in the Alpha disappeared in Preview 1. The bits were still there, but all the WinRT stuff- nope. I realize the focus was on the new stuff (Win32), but hey.

@terrycox huh? It's not just Win32. The WinUI UWP templates are still there.

I have played around with Validation. It is quite instable. It crashes a lot.
I'm using an improved version of ValidationBase baseclass with an extra AllError property. Use it for a kind of 'Validation Summary' (ListView)
public class ValidationBase : INotifyPropertyChanged, INotifyDataErrorInfo {

    public event PropertyChangedEventHandler PropertyChanged;
    public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

    protected void SetValue<T>(ref T currentValue, T newValue, [CallerMemberName] string propertyName = "") {
        if (!EqualityComparer<T>.Default.Equals(currentValue, newValue)) {
            currentValue = newValue;
            OnPropertyChanged(propertyName, newValue);
        }
    }

    readonly Dictionary<string, List<ValidationResult>> _errors = new Dictionary<string, List<ValidationResult>>();

    public bool HasErrors {
        get {
            return _errors.Any();
        }
    }
    public IEnumerable GetErrors(string propertyName) {
        return _errors[propertyName];
    }

    private void OnPropertyChanged(string propertyName, object value) {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        Validate(propertyName, value);
    }

    private void AddErrors(string propertyName, IEnumerable<ValidationResult> results) {
        if (!_errors.TryGetValue(propertyName, out List<ValidationResult> errors)) {
            errors = new List<ValidationResult>();
            _errors.Add(propertyName, errors);
        }

        errors.AddRange(results);
        ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(AllErrors)));
    }

    private void ClearErrors(string propertyName) {
        if (_errors.TryGetValue(propertyName, out List<ValidationResult> errors)) {
            errors.Clear();
            ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(AllErrors)));
        }
    }

    public void Validate(string memberName, object value) {
        ClearErrors(memberName);
        List<ValidationResult> results = new List<ValidationResult>();
        bool result = Validator.TryValidateProperty(
                value,
                new ValidationContext(this, null, null)
                {
                    MemberName = memberName
                },
                results
                );

        if (!result) {
            AddErrors(memberName, results);
        }
    }

    public IEnumerable<ValidationResult> AllErrors => _errors.Values.SelectMany(v => v);
}

public class Employee : ValidationBase {

    private string name;
    private double _salary;

    public Employee(string name, double salary) {
        Name = name;
        Salary = salary;
    }

    [MinLength(4)]
    [MaxLength(6)]
    public string Name {
        get { return name; }
        set { SetValue(ref name, value); }
    }

    [Range(0, 10000)]
    public double Salary {
        get { return _salary; }
        set { SetValue(ref _salary, value); }
    }
}

<Page x:Class="App23.MainPage"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:local="using:App23"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"
      mc:Ignorable="d">

    <StackPanel HorizontalAlignment="Center"
                VerticalAlignment="Center"
                Spacing="12"
                Width="300"
                Orientation="Vertical">
        <TextBox Text="{x:Bind Employee.Name, Mode=TwoWay}" />
        <NumberBox Value="{x:Bind Employee.Salary, Mode=TwoWay}" />
        <Button x:Name="myButton" Click="myButton_Click">Click Me</Button>
        <ListView ItemsSource="{x:Bind Employee.AllErrors, Mode=OneWay}" />
    </StackPanel>
</Page>

Why don't you look through the repo to see the bugs people have reported in Preview 1?

Oh we definitely are! I put this issue together so that we have an easy way of seeing peoples biggest blockers. Using an issue like this is also a tool that helps aggregate upvotes on issues, which gives us an easier view into how widespread the issue is.

https://github.com/microsoft/microsoft-ui-xaml/issues/2440

Thanks @anawishnoff for creating this issue. Addressing bugs has been a long standing problem with UWP and I'm glad to finally see them being addressed head-on and talked about.
A focus here will ensure WinUI 3.0 is smooth for developers to use. I look forward to trying out future previews!

Webview2 is always on top of other controls so other controls with animations are hidden behind the webview2 control. I think this used to be called the 'Airspace problem'.

Win2D! Not that this is a bug, but it would be a much-needed addition to Preview 2, rather than waiting until later.

It would be great if #2602 could be addressed.

Not sure if it qualifies as a bug, but can you please add header files and idl files for WRL? These are required to get win2d working (see https://github.com/microsoft/Win2D/issues/707). I created them manually from the .winmd file (not sure if I did it correctly) but a lot of manual editing was required afterwards.

TreeView with derived TreeViewNodes crashes in WinUI3 Desktop #2699

DataGrid Not Displaying in WinUI3 Desktop #2703

Unable to Enter Text into TextBox inside ContentDialog in WinUI3 Desktop #2704

NavigationView inside ContentDialog causes crash #2713

Change in Appearance of AppBarButton with Flyout on CommandBar in WinUI3 Desktop #2714

Unable to drop files onto Grid in WinUI3 Desktop #2715

FileOpenPicker, FileSavePicker, and FolderPicker break in WinUI3 Desktop #2716

Not exactly a blocking bug, but would be nice to have the TitleBar customization back in Preview 2!
Window.SetTitleBar method is missed in WinUI/Uwp #2559

Working ObservableCollections is a must!

It would be nice to see some progress on Dispatcher too.

Unable to drop items from ListView onto Grid in WinUI3 Desktop #2782

Unable to move item (drag and drop) inside TreeView in WinUI3 Desktop #2783

Any news on the Preview 2 release date, with working observable collections ;) ?

@Wigmund Tune into today's WinUI Community Call, if possible (Preview 2 seems quite close to release by now).


Adds pipeline for comparing postgres versions

Adresses https://github.com/systemslab/popper/issues/338

awesome!


How to stop player at a precise point in time?

I don't think there is a way to stop playing at a certain point. For example, if I wanted the player to stop playing at 3 seconds but the callback rate is every 5 seconds then I won't know that the player has hit 3 seconds before 5 seconds. To fix this I would have to set the call back rate to one second. However, this means that if I want to stop at a even more precise time then I would have to increase the callback rate further. Is there a better way to stop at a precise time?
I think what I am looking for is: https://developer.apple.com/documentation/avfoundation/avplayer/1388027-addboundarytimeobserver ?
Could you help me expose this method in react native as I am not a swift developer? I would really appreciate it. Thank you!

Same problem here


react-native Block-scoped declarations

After following the react-native tutorial I am getting this error when running a simple test on a real project.
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode

Update your version of node; put 'use strict'; on top of your file. Can also try out https://github.com/facebook/jest/tree/master/examples/react-native

Upgrading to node 6 fixed the "use strict" requirement but now its complaining about flow types in node modules. I can test files that use flow but as soon as I test a file that includes a node module that uses flow it errors out. Keep in mind this project runs in react native without any problems.

If they aren't precompiled you'll need to add it to your preprocessorIgnorePatterns: http://facebook.github.io/jest/docs/tutorial-react-native.html#preprocessorignorepatterns-customization

Is there a reason the react-native preset doesn't have babel configured the same way react-native configures babel?
At very least this should be moved up in the docs. It is very common for react-native modules to not be precompiled.

The problem is that unfortunately react-native's packager compiles everything which is horribly slow. We should really stop doing this (and are planning to on the RN team). In Jest we made the choice to ignore most node modules by default and enable users to whitelist the ones that aren't precompiled. We might want to update the error that Jest throws to hint at this.


Fix for LP1986856

There is probably a more reactive way of handling the 1.25 switch, but this seemed unobtrusive. Welcome to suggestions though.
Fixes https://launchpad.net/bugs/1986856

We'll follow up with this in a future PR to remove snap channel options (to ensure we use the default from k8s-core).


🐛 Bug Report: Cannot import local node-library in plugins or packages

📜 Description
I'm not sure if this is a bug or if I'm missing something but I didn't find any answer on documentation or get any on Discord. Sorry if this shouldn't be open here 🙏
I want to share code between two backend plugins generated with backstage-cli new. In the documentation it is written :

Plugins must never communicate with each other directly through code, they may only communicate over the network. Plugins that wish to expose an external interface for other plugins and modules to use are recommended to do so through a node-library package

I tried to create a local node-library with the CLI but I was expecting being able to import it like I do with my backend plugins in the backend (import { whatever } from 'my-node-library').
When I try to yarn add <my-node-lib> I get the following error : Error: https://registry.npmjs.org/<my_lib>: Not found.
Since backstage is a monorepo I'm assuming importing with ../../packages/<my-node-lib> is not the right way.
The generated README in the node-library indicates to use yarn add to install the lib.
I also tried using plugin-node from backstage-cli but I get the same result.
What is the good way to share code between plugins ? Should I publish my node library on my company registry ?
👍 Expected behavior
It should be possible to share code between plugins thanks to a node-library like recommended in the documentation and easily import it.
👎 Actual Behavior with Screenshots
It actually fails on the install of the node-library with yarn add
👟 Reproduction steps

Create a new backstage repo with npx @backstage/create-app@latest
Use backstage-cli to create a new node-library
[Optional] Use backstage-cli to create a new backend-plugin
Try to import the node-library in the backend or in a plugin

📃 Provide the context for the Bug.
No response
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

Hi @Julien-Hery, this works for me. I've seen this come up from time to time and we've never been able to pin down the actual cause. This is where having your environment details would be handy to include - yarn backstage-cli info.
As a workaround you can simply add the package manually to the package.json where you want to use it.
Steps I took:

Based in on the current Demo site repo - https://github.com/backstage/demo
Navigated to the /plugins folder
Ran yarn new
Picked "node-library"
Called it "node-lib"
Once generated navigated to the /plugins/catalog-backend-module-backstage folder
Ran yarn add @internal/node-lib
Success, no errors

Ah, worth noting that the Demo site repo is using Yarn 3 but this "should" work with Yarn 1

Can you include details steps of how you got to this point, things like what folder you were in could help. Thanks!

Ok, just for the sake of making sure to follow what you have I create a new Backstage instance so I would be on Yarn 1 and I get the same error. 😢

Hello @awanlin :)
Oh you're right I'm on Yarn 1 🤔 I'll try to upgrade to see if it fixes my issue !
In case this helps :
$ backstage-cli info
OS:   Darwin 23.0.0 - darwin/x64
node: v20.10.0
yarn: 1.22.21
cli:  0.26.4 (installed)
backstage:  1.26.4

Dependencies:
  @backstage/app-defaults                                          1.5.4
  @backstage/backend-app-api                                       0.7.1, 0.7.5
  @backstage/backend-common                                        0.21.7, 0.22.0
  @backstage/backend-defaults                                      0.2.17
  @backstage/backend-dev-utils                                     0.1.4
  @backstage/backend-openapi-utils                                 0.1.10
  @backstage/backend-plugin-api                                    0.6.17, 0.6.18
  @backstage/backend-tasks                                         0.5.22, 0.5.23
  @backstage/backend-test-utils                                    0.3.7
  @backstage/catalog-client                                        1.6.4, 1.6.5
  @backstage/catalog-model                                         1.4.5, 1.5.0
  @backstage/cli-common                                            0.1.13
  @backstage/cli-node                                              0.2.5
  @backstage/cli                                                   0.26.4
  @backstage/config-loader                                         1.8.0
  @backstage/config                                                1.2.0
  @backstage/core-app-api                                          1.12.4
  @backstage/core-compat-api                                       0.2.4, 0.2.5
  @backstage/core-components                                       0.14.5, 0.14.7
  @backstage/core-plugin-api                                       1.9.2
  @backstage/dev-utils                                             1.0.31
  @backstage/e2e-test-utils                                        0.1.1
  @backstage/errors                                                1.2.4
  @backstage/eslint-plugin                                         0.1.7
  @backstage/frontend-plugin-api                                   0.6.4, 0.6.5
  @backstage/integration-aws-node                                  0.1.12
  @backstage/integration-react                                     1.1.26, 1.1.27
  @backstage/integration                                           1.10.0, 1.11.0
  @backstage/plugin-api-docs                                       0.11.4
  @backstage/plugin-app-backend                                    0.3.65
  @backstage/plugin-app-node                                       0.1.17
  @backstage/plugin-auth-backend-module-atlassian-provider         0.1.9
  @backstage/plugin-auth-backend-module-aws-alb-provider           0.1.9
  @backstage/plugin-auth-backend-module-azure-easyauth-provider    0.1.0
  @backstage/plugin-auth-backend-module-bitbucket-provider         0.1.0
  @backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.0
  @backstage/plugin-auth-backend-module-gcp-iap-provider           0.2.12
  @backstage/plugin-auth-backend-module-github-provider            0.1.14
  @backstage/plugin-auth-backend-module-gitlab-provider            0.1.14
  @backstage/plugin-auth-backend-module-google-provider            0.1.14
  @backstage/plugin-auth-backend-module-guest-provider             0.1.3
  @backstage/plugin-auth-backend-module-microsoft-provider         0.1.12
  @backstage/plugin-auth-backend-module-oauth2-provider            0.1.14
  @backstage/plugin-auth-backend-module-oauth2-proxy-provider      0.1.10
  @backstage/plugin-auth-backend-module-oidc-provider              0.1.8
  @backstage/plugin-auth-backend-module-okta-provider              0.0.10
  @backstage/plugin-auth-backend                                   0.22.4
  @backstage/plugin-auth-node                                      0.4.12, 0.4.13
  @backstage/plugin-auth-react                                     0.1.1
  @backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.15
  @backstage/plugin-catalog-backend-module-unprocessed             0.4.4
  @backstage/plugin-catalog-backend                                1.21.1
  @backstage/plugin-catalog-common                                 1.0.22, 1.0.23
  @backstage/plugin-catalog-graph                                  0.4.4
  @backstage/plugin-catalog-import                                 0.10.10
  @backstage/plugin-catalog-node                                   1.11.1
  @backstage/plugin-catalog-react                                  1.11.3, 1.12.0
  @backstage/plugin-catalog-unprocessed-entities-common            0.0.1
  @backstage/plugin-catalog                                        1.19.0, 1.20.0
  @backstage/plugin-events-backend                                 0.3.4
  @backstage/plugin-events-node                                    0.3.3
  @backstage/plugin-home-react                                     0.1.12
  @backstage/plugin-home                                           0.7.3
  @backstage/plugin-kubernetes-backend                             0.17.0
  @backstage/plugin-kubernetes-common                              0.7.5
  @backstage/plugin-kubernetes-node                                0.1.11
  @backstage/plugin-kubernetes-react                               0.3.4
  @backstage/plugin-kubernetes                                     0.11.9
  @backstage/plugin-org                                            0.6.24
  @backstage/plugin-permission-backend-module-allow-all-policy     0.1.14
  @backstage/plugin-permission-backend                             0.5.41
  @backstage/plugin-permission-common                              0.7.13
  @backstage/plugin-permission-node                                0.7.28, 0.7.29
  @backstage/plugin-permission-react                               0.4.22
  @backstage/plugin-proxy-backend                                  0.4.15
  @backstage/plugin-scaffolder-backend-module-azure                0.1.9
  @backstage/plugin-scaffolder-backend-module-bitbucket-cloud      0.1.7
  @backstage/plugin-scaffolder-backend-module-bitbucket-server     0.1.7
  @backstage/plugin-scaffolder-backend-module-bitbucket            0.2.7
  @backstage/plugin-scaffolder-backend-module-gerrit               0.1.9
  @backstage/plugin-scaffolder-backend-module-gitea                0.1.7
  @backstage/plugin-scaffolder-backend-module-github               0.2.7
  @backstage/plugin-scaffolder-backend-module-gitlab               0.3.3
  @backstage/plugin-scaffolder-backend                             1.22.4
  @backstage/plugin-scaffolder-common                              1.5.1, 1.5.2
  @backstage/plugin-scaffolder-node-test-utils                     0.1.3
  @backstage/plugin-scaffolder-node                                0.4.3
  @backstage/plugin-scaffolder-react                               1.8.4
  @backstage/plugin-scaffolder                                     1.19.3
  @backstage/plugin-search-backend-module-catalog                  0.1.23
  @backstage/plugin-search-backend-module-pg                       0.5.26
  @backstage/plugin-search-backend-module-techdocs                 0.1.22
  @backstage/plugin-search-backend-node                            1.2.21
  @backstage/plugin-search-backend                                 1.5.7
  @backstage/plugin-search-common                                  1.2.11
  @backstage/plugin-search-react                                   1.7.10, 1.7.11
  @backstage/plugin-search                                         1.4.10
  @backstage/plugin-techdocs-backend                               1.10.4
  @backstage/plugin-techdocs-module-addons-contrib                 1.1.9
  @backstage/plugin-techdocs-node                                  1.12.3
  @backstage/plugin-techdocs-react                                 1.2.3
  @backstage/plugin-techdocs                                       1.10.4
  @backstage/plugin-user-settings                                  0.8.5
  @backstage/release-manifests                                     0.0.11
  @backstage/repo-tools                                            0.8.0
  @backstage/test-utils                                            1.5.4
  @backstage/theme                                                 0.5.3, 0.5.5
  @backstage/types                                                 1.1.1
  @backstage/version-bridge                                        1.0.8

It works with Yarn 4 🎉
Should we rename the issue to Cannot import local node-library with Yarn v1 ?


fix: datastore emulator startup race condition

The start_datastore_emulator() function that runs the gcloud emulator actually will run two commands.
First it will check whether /builder/home/.config/gcloud/emulators/datastore exists, if not it will run cloud_datastore_emulator create with the test project ID, which makes the directory. Then it will follow up with the actual datastore emulator command.
The problem is with the first command, if multiple datastore emulator tests are ran at the start without /builder/home/.config/gcloud/emulators/datastore existing, it will try to run cloud_datastore_emulator create multiple times, which will fail, as by the time it's ran, the directory would have started existing.
This fix makes it so one data store emulator is ran by itself at the start (lib-tests), before any concurrent tests start.
Also prints the output on data store timeout to make it easier to debug.

thanks for debugging this!


Remove 'bdist_wheel universal=True' since the package is Python 3.6.1+

This is just a minor cleanup for the filename of the generated wheel, which includes py2 and might confuse users.

Thanks @s-weigand - doesn't this signal that the project has no compiled extensions? Is the reason to remove just so that py2 doesn't show up in the versions for the wheel?

The universal bdist_wheels indicates that the wheel is for python2 and python3 AND has no compiled extension.
And yeah the only difference will be py2 not being in the filename since python_requires already tells pip that it doesn't work with python2. So yeah it is just a minor beauty thing 😝

always up for beauty things - thanks!


Resync issue on windows

Hello dynamicdan,
I found an issue on windows running resync command(node.exe src\app --resync).
I am still getting error: 'Failed to find root folder.'
Issue is in src\file-record.js in method getRoot.
I found cause of the problem: path.dirname(this.filePath) returns path with '/' and in config is '' in filepath.
I rewrote the method to:
method.getRoot = function () {
// cache
if (this.rootDir) return this.rootDir;
var root = path.dirname(this.filePath).replace(/\//g, "\\");//issue
while (!this.config.roots[root]) {
    var up = path.dirname(root).replace(/\//g, "\\");//issue

    if (root === up) throw new Error('Failed to find root folder.');
    root = up;
}

return root;

};
I didn't want to make an commit, because I don't fully understand node.js and don't know what is affected in solution. Could you please test this fix on mac? On windows it looks like it works. Files are resynced.
And also for the future. It would be nice to have flag in config 'resyncOnStart' and it would only resynced files from server which are newer than local ones.(I think this check is already on conflict resolution)
Thanks,
Jakub

Thanks Jakub for reporting this. I also found this out recently and created a similar fix but it wasn't "strong" enough. There are other issues when handling the root path and searching for it in script. Now that I am forced to use windows for a customer, I will invest more time into this issue.
My workaround for now was to reset the file before I work on it (clear it and save to re-download).
Please let me know if any other path related issues popup with your fix. You could also try the --test option to run further tests (non-record-destructive tests).
The "resyncOnStart" config option currently exists as "_resyncFiles". It is not officially supported but you can use it for now (exactly the same as --resync).
Only syncing newer files is kind of a performance hit. I have to query for all the records anyway and have the new data. Adding a comparison of timestamps is then added complexity that is not needed IMO. In any case, I find that ~30 records takes < 3 seconds. So 100 records take less than 10 seconds and most setups don't have more... at least not yet. I am working on a search/auto-download record option so if --resync becomes a performance issue then I will re-visit it.

Thanks for the quick answer :)
Ok, if something will pop up I will let you know. For now, all files are resynced.
That's also an option to resync all files on load. This config option(_resyncFiles) is working for me. I don't mind a performance hit, because I am working on project with tens of people, so it is quite important for me, to have latest files.
And btw really nice work with the tool. Thanks, it helped me a lot

I've just fixed this in the latest version 2.4.7.
Note that your fix did not cover all scenarios but was close. I have now changed support for windows. You will need to update your config root path to my unix/universal style with "/" instead of "\" slashes.

Thanks. I've tested that. It works.


3d point cloud is only visible very close to camera

|---|---|
|librealsense|2.35.2 RELEASE|
|OS|Linux|
|Name|Intel RealSense SR305|
|Serial Number|636204001701|
|Firmware Version|<IP_ADDRESS>|
|Camera Locked|YES|
|Product Line|SR300|
|Asic Serial Number|636204001701|
|Firmware Update Id|636204001701|
Please provide a description of the problem
3d point cloud is only visible very close to camera.
-Object is completely compressed in a cone (3d cone), the distance it is measuring is like 100-200 mm only, beyond that if I place an object, it does not show that.
same realsenseviewer on windows with same camera, shows correct image at distances normally 0.1 - 1 meter or more.
-I suspect issue is that image cone is generated and is distorting 3d point cloud. I am not sure if this is issue of firmware version, if so how can I update that?

Hi @readblack1234   It sounds as though you are having problems with viewing the point cloud in Linux with the RalSense Viewer, but do not have that problem when using the Viewer in Windows.  Is that correct, please?
As firmware is stored inside the camera hardware and not on the computer (and therefore gets carried with the camera between machines), I would expect problems to also manifest on Windows if the issue was related to the firmware.

This issue was reported earlier a well, I used this to resolve that
https://support.intelrealsense.com/hc/en-us/community/posts/360044304633-Is-depth-broken-in-my-SR305
https://github.com/IntelRealSense/librealsense/issues/6373#issuecomment-630584604
Basically, CUDA had to be turned off.
Now, I am having issue with building  specific "rs-pcl" binary from examples.
I am getting following error
"
~/librealsense/wrappers/pcl/build$ make
Scanning dependencies of target rs-pcl
[ 25%] Building CXX object pcl/CMakeFiles/rs-pcl.dir/rs-pcl.cpp.o
[ 50%] Linking CXX executable rs-pcl
/usr/bin/ld: /usr/local/lib/libglfw3.a(posix_thread.c.o): undefined reference to symbol 'pthread_getspecific@@GLIBC_2.17'
/lib/aarch64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
pcl/CMakeFiles/rs-pcl.dir/build.make:371: recipe for target 'pcl/rs-pcl' failed
make[2]: *** [pcl/rs-pcl] Error 1
CMakeFiles/Makefile2:85: recipe for target 'pcl/CMakeFiles/rs-pcl.dir/all' failed
make[1]: *** [pcl/CMakeFiles/rs-pcl.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2""
Is  there a fix for that?

Also, attaching the console output when realsense sdk was installed. It shows libglfw3.a installed.
231_installed.txt

Reading the discussion in the link below may give you some ideas.
https://github.com/IntelRealSense/librealsense/issues/6784

Hi @readblack1234   Do you still require assistance with this case, please?   Thanks!

Thanks @MartyG-RealSense , I was able to resolve this by using CMake example in examples. That was very helpful.

That is great to hear - thanks very much for the update !

I've commented on a closed issue #6373 - I believe CUDA can be made to work it's a matter of fixing how bit sift operations are done on GPU vs CPU.

Hi @xavirostudio   I have now re-opened that case for another look.  Thanks for your report!

Adding a note to keep this case open for a further time period.

Hi @readblack1234   As you had a successdul outcome, I will close this case now.   Thanks!
@xavirostudio   As your CUDA question is on another case, I can detail with that there.  Thanks again for your report.