<FromGitter>
<Blacksmoke16> got some of it integrated into rest of Athena now, turned out quite nice if i must say so myself :p
<FromGitter>
<Blacksmoke16> sorry `Foo` is a custom assertion that checks if the value `== "foo"`
antoszka_ has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 264 seconds]
z64 has quit [*.net *.split]
antoszka has quit [*.net *.split]
PixeLInc_ has quit [*.net *.split]
<FromGitter>
<Blacksmoke16> updated `property` field to include information about root object, `"property": "Object(Foo).name",`
<FromGitter>
<Blacksmoke16> also correctly handles hash and array key/indices
f1reflyylmao has joined #crystal-lang
f1refly has quit [Ping timeout: 260 seconds]
chachasmooth has quit [Ping timeout: 240 seconds]
chachasmooth has joined #crystal-lang
z64 has joined #crystal-lang
_whitelogger has joined #crystal-lang
_whitelogger has joined #crystal-lang
f1reflyylmao has quit [Quit: bye fags]
f1refly has joined #crystal-lang
zorp has quit [Ping timeout: 265 seconds]
dead10cc has joined #crystal-lang
dead10cc has left #crystal-lang [#crystal-lang]
_whitelogger has joined #crystal-lang
PixeLInc has joined #crystal-lang
<FromGitter>
<Nicolab> @maxbertinetti I saw this but it doesn't work at my house and at a colleague's, I don't know why (when I ctrl + space there is always the same message, I don't remember which one. As soon as I retest I let know).
<FromGitter>
<Nicolab> @maxbertinetti I just tested, each ctrl+space displays the message "Loading...".
<FromGitter>
<Nicolab> on hover I have the message : `Unsupported Markup content received. Kind is:`
<raz>
blacksmoke16: now the hard part. how does it work with my ORM? :P
<raz>
j/k, i think targeting a specific orm is fine
<FromGitter>
<Nicolab> @raz what is your ORM?
alexherbo2 has joined #crystal-lang
alexherbo24 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 240 seconds]
alexherbo24 is now known as alexherbo2
<raz>
oh, i meant that as "my fav orm"
<raz>
hinting at orm pluggability. but wasn't serious, that should prob not be a goal (or only much later)
<FromGitter>
<maxbertinetti> @Nicolab for Crystalline try to use the new binary. Remove anything in VSCode that can conflict with the two packages.
<FromGitter>
<maxbertinetti> @Nicolab which OS you are running?
<FromGitter>
<Blacksmoke16> raz: it should work with any orm. However only granite would support the annotation approach. The others would have to do it via code manually
<FromGitter>
<Blacksmoke16> Well probably could use annotations but would probably have to like retype the ivar and apply it if you're not able to apply it directly to the column def
alexherbo2 has quit [Ping timeout: 246 seconds]
yxhuvud has quit [Remote host closed the connection]
alexherbo2 has joined #crystal-lang
yxhuvud has joined #crystal-lang
<FromGitter>
<herrcykel> Hi people! I have a piece of code that no longer works after upgrading crystal. 0.33 seems to be the breaking point. The code uses inotify api to watch for new files in a directory. The first issue is a Proc not being called when doing `spawn proc.call(arg)`, 2nd is Ctrl-C no longer being trapped. The code can be tested by running it and then creating a file in the working directory, which should show the
<FromGitter>
... different behavior between docker images `crystallang/crystal:0.32.1` and `crystallang/crystal:0.33.0`
<FromGitter>
<herrcykel> Relevant parts should be `start` method and below. Any help appreciated!
<raz>
blacksmoke16: yea no worries. focus on a package that works. rest can come later. rails, django etc. are successful because they come w/ batteries included.
<FromGitter>
<Blacksmoke16> @herrcykel maybe try to reduce the code? Like is all that C stuff required to replicate the issue?
<FromGitter>
<Blacksmoke16> raz: thats how i been making all my stuff 😉 this ones the fanciest tho. Learned some new patterns that have been treating me well
<FromGitter>
<Blacksmoke16> ``` code paste, see link``` ⏎ ⏎ Like this is what gets included into the type. Was able to move the logic of iterating ivars and stuff into the metadata class itself, versus like building that out and returning an array [https://gitter.im/crystal-lang/crystal?at=5f70a6066a6e094525bd3a21]
<FromGitter>
<Blacksmoke16> its also cached so only is built once when that type first goes to be validated
<FromGitter>
<herrcykel> @Blacksmoke16 ya sorry ik it's a bit much. I did try to replace waiting for a file to be created with waiting for data on a socket but that does not replicate the issue :(
<FromGitter>
<herrcykel> Not sure if it's due to being inside the `server.accept` block
<FromGitter>
<Blacksmoke16> Hmm
<FromGitter>
<Blacksmoke16> What happens if you add a Fiber.yield after the spawn proc.call
<FromGitter>
<herrcykel> Ha nice, that made the proc run! Thanks!!
<FromGitter>
<Blacksmoke16> if i had to guess there was never anything in the loop that blocked the fiber, so it never could switch
<FromGitter>
<Blacksmoke16> however im not sold on if that should be the solution, or refactor things so you dont need to do that :shrug:
<FromGitter>
<naqvis> `Fiber.yield` will tell the scheduler to execute the other fiber. As main Fiber is in sleep mode, while other fiber is under tight loop, so definitely would require a way to notify scheduler to execute other fiber
<FromGitter>
<naqvis> also better to move `proc` code above the loop, as it doesn't make sense to create this in loop (assuming you won't be changing the contents of this proc during that loop), its just argument which is different ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5f70af006a6e094525bd5133]
<FromGitter>
<naqvis> another thing, your proc is accepting a `String` while `full_name` is `String?`, so you would need to call `full_name.not_nil!` when calling this proc
<FromGitter>
<Blacksmoke16> he did have a `next if full_name.nil?` which would prob handle that
<FromGitter>
<naqvis> yeah, but he is calling the proc beneath that and don't think compiler will be assuming that var beneath this line is not null
<FromGitter>
<Blacksmoke16> :shrug: dunno
<FromGitter>
<herrcykel> Ctrl-C not working is still an issue. Any ideas?
<FromGitter>
<herrcykel> Ty for helping out!
<FromGitter>
<naqvis> `Signal::INT.reset` try this
<FromGitter>
<herrcykel> Before `Signal::INT.trap ...`? Made no difference
<FromGitter>
<naqvis> after
<FromGitter>
<naqvis> :P
<FromGitter>
<naqvis> @Blacksmoke16 you are right, compiler is smart enough to not treat optional variable as nil, beneath `next if name.nil?` check. https://play.crystal-lang.org/#/r/9rcy
<FromGitter>
<Blacksmoke16> 👍
zorp has joined #crystal-lang
<FromGitter>
<herrcykel> @naqvis `reset` makes Ctrl-C terminate the program. Same effect as having no `Signal::INT.trap`, which is expected I guess
<FromGitter>
<Blacksmoke16> what happens if you put that in the `spawn do` block?
<FromGitter>
<Blacksmoke16> put it*
<FromGitter>
<herrcykel> No difference :/
<FromGitter>
<Blacksmoke16> rip, well im out of ideas
<FromGitter>
<naqvis> well, i just figured out that you will need to put fiber in some suspended state for it to give some breathing time to other events :P
<FromGitter>
<naqvis> also notice `reader.read(data)` is blocking call, if you hit `ctrl-c` while no event data has been read by this call, it will still pause, but as soon as this call returns, code inside `Signal::INT.trap` block get executed
<FromGitter>
<naqvis> sleep 0 works as well
<FromGitter>
<herrcykel> The trap works in 0.33 too if I use fd 0 instead of the one returned from `inotify_init`
HumanGeek has quit [Ping timeout: 256 seconds]
HumanGeek has joined #crystal-lang
<FromGitter>
<naqvis> @herrcykel Got the reason of why it isn't catching the sigint :P
<FromGitter>
<naqvis> the reason is `IO::FileDescriptor` created is blocking and it hold the fiber in blocking mode.
<FromGitter>
<naqvis> @herrcykel you better use `int inotify_init1(int flags);` instead of first version or else you should call ⏎ ⏎ ```if (fcntl(fd, F_SETFL, O_NONBLOCK) < 0) // error checking for fcntl ⏎ exit(2);``` [https://gitter.im/crystal-lang/crystal?at=5f70d143417bf140aa18471d]
<FromGitter>
<naqvis> `IO::FileDescriptor` blocking will be different from file descriptor you retrieve via `inotify_init`
<FromGitter>
<herrcykel> Unless you're referring to some other change :)
alexherbo28 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 256 seconds]
alexherbo28 is now known as alexherbo2
<FromGitter>
<naqvis> @herrcykel Seems Linux Kernel changes is causing that, I just tested the code with `C.inotify_init1(C::O_NONBLOCK)` and it works without any further change to your code
<FromGitter>
<naqvis> you don't need to call `blocking = false`