<FromGitter>
<codenoid> how to catch Terminated signal
<FromGitter>
<codenoid> *when i do `pkill -f appidentity` to my app
<FromGitter>
<codenoid> ::KILL ? i'll try
<FromGitter>
<codenoid> but at_exit won't do the job
rohitpaulk has quit [Ping timeout: 268 seconds]
<FromGitter>
<codenoid> ::TERM
<FromGitter>
<bew> You can't
<FromGitter>
<bew> Maybe term but it's not recommended
<FromGitter>
<bew> Why do you want to catch it?
<FromGitter>
<bew> Checkout `Signal#trap`
<FromGitter>
<codenoid> Signall::TERM.trap do the job
snsei has joined #crystal-lang
<FromGitter>
<codenoid> to close browser that called by selenium 👍
<crystal-gh>
[crystal] asterite opened pull request #6074: Explosive birth of automatic casts! (master...feature/automatic_cast) https://git.io/vpK1b
<FromGitter>
<asterite> oprypin I saw that you have Celeste in your Steam wish list and thought I could give it to you as a present (it's an excellent game! how come you haven't played it yet?). But I think the Steam restrictions between countries still apply, so all I can offer for now is this: https://github.com/crystal-lang/crystal/pull/6074
gizmore|2 has joined #crystal-lang
<FromGitter>
<bew> 'lly shit that' s a gift ❤️
gizmore has quit [Ping timeout: 260 seconds]
<FromGitter>
<asterite> :D
<FromGitter>
<bew> You're amazing, I wonder, what's your background?
<FromGitter>
<asterite> The apartment we are renting has this wall with a Chinese style painting... it came like that
<FromGitter>
<bew> :P nice one
<FromGitter>
<asterite> Speaking seriously (though the above is true)... I just studied computer science (and didn't finish the career)
<oprypin>
asterite, omg that's amazing. good thing there are those gifting restrictions huh. no but seriously I'm gonna play the game eventually. can buy the game, just can't buy time
<FromGitter>
<asterite> Yeah, restrictions are nice. In this case it's having to specify a type in one place instead of a thousand. And Celeste, yeah, time is hard to find...
Yxhvd has quit [Quit: No Ping reply in 180 seconds.]
Yxhuvud has joined #crystal-lang
<FromGitter>
<girng> that game looks epic
<FromGitter>
<gdotdesign> @faustinoaq the new Gitbook is amazing :D
<FromGitter>
<gdotdesign> tried to convert a book to the new version but it seems it's a completely separate app
<FromGitter>
<bararchy> @asterite hot damn dude!!! Nice PR, you made me a happy man!
<FromGitter>
<girng> @FromIRC nah can't, not a bug
<FromGitter>
<girng> @faustinoaq can't do it sir, sorry
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
<FromGitter>
<faustinoaq> @asterite Oh, Thank you! #6074 is amazing!!! ✨
<FromGitter>
<DRVTiny> @faustinoaq Yeah, very wonderful suprprise!
<crystal-gh>
[crystal] asterite opened pull request #6077: Bug: initialize with {% @type %} (master...bug/initialize-with-type) https://git.io/vp6CU
<FromGitter>
<DRVTiny> Is it possible somehow to use closures instead of blocks? For example: ⏎ ⏎ ```f = ->(i : Int32) { i**i } ⏎ a = [1,2,3,4].each_with_object([] of Int32, f)``` ⏎ ⏎ This does not work, each_with_object expects block, but not closure aka Proc ... [https://gitter.im/crystal-lang/crystal?at=5af189af1eddba3d04df8917]
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<DRVTiny> OK, i can use &f :)
shalmezad has joined #crystal-lang
<crystal-gh>
[crystal] carlhoerberg opened pull request #6079: Optimize Tuple#to_a by preallocate Array (master...Tuple#to_a) https://git.io/vp64d
<z64>
anyone able to help with an issue i'm experiencing with Zlib/Flate::Reader? i'm working with a blob that i can't read because the IO locks forever and i'm not sure how to figure out why. i have a repo with reproducable example here: https://github.com/z64/zlib-freeze
kurko_ has joined #crystal-lang
<FromGitter>
<hmans> Love you, @asterite
epergo_ has quit [Quit: Leaving]
<jeromegn>
I'm having a weird pointer problem in my C (well, C++) bindings. I'm passing a struct from C like: {int, void**}, and in Crystal I have the equivalent {LibC::Int, Void**}. I use a Slice.new(s.pointers, s.length) to get a slice of pointers and convert to my Crystal objects. I inspect the pointers and they're different (and wrong) in Crystal.
<FromGitter>
<bararchy> jeromegn wrog in what way?
<FromGitter>
<bararchy> *wrong
<jeromegn>
I've been trying to cast explicitly as a Slice(UInt8), but it only takes a Int argument for its size, while a LibC::Int is a Int32. my Crystal is rusty, not sure I can cast it to the more generic Int from Int32!
<jeromegn>
@bararchy: oh, well since the pointer is different, I can't use them later.
<jeromegn>
they point at the wrong place :)
<jeromegn>
so I get a segfault
<FromGitter>
<bararchy> jeromegn Can you share a code example of the binding and the way you call it ?
<jeromegn>
sure, gimme a minute :)
<FromGitter>
<bararchy> I'm pretty sure you can do Slice(Int32).new etc..
<jeromegn>
I removed the lines where I print debug info, but basically I printed the pointers from C, and then from Crystal and they differed.
snsei has quit [Ping timeout: 276 seconds]
<FromGitter>
<bararchy> I don't really get what the CPP does, maybe oprypin or RX14 can give a hand? or @bew
<RX14>
what?
<FromGitter>
<bararchy> RX14, looking at the above gist, he says the Crystal is showing wrong pointer value
<jeromegn>
oh hey RX14 :) I think I based using @[Link] with compiled C++ code from one of your repos.
<jeromegn>
yes, my slice has the wrong pointers, it has the right length and type though.
<RX14>
thats clearly not the whole code
<RX14>
and isn't PersistentValuePtr* a PersistentValue**
snsei has joined #crystal-lang
<jeromegn>
hmm
<RX14>
and hence wrong in your bindings
<jeromegn>
PersistValuePtr is a Void*
<jeromegn>
void*
<RX14>
yes
<jeromegn>
ah
<RX14>
so PersistValuePtr is a Void**
<RX14>
you should let void* be void*
<RX14>
and not PersistentValue*
<RX14>
well definitely not that
<jeromegn>
I should let void* be void* in C?
<RX14>
const v8::FunctionCallbackInfo<v8::Value>
<RX14>
thats a template
<RX14>
your v8 function isn't even extern C
<RX14>
why are you trying to bind C++ manually
<RX14>
go use bindgen
<jeromegn>
I tried that, but there are a lot of corner cases it can't handle right now, like smart pointers
<jeromegn>
I'm using a bridge from a golang package I had been using. it's been working fine hehe. I didn't show it in the snippet, but it's all wrapped in an extern "C"
<RX14>
Then you should show the whole code
<jeromegn>
sure, it's a bit beefy, but let me update the gist
<RX14>
Especially since you stripped templates out
qard has quit [Read error: Connection reset by peer]
<jeromegn>
it'S messy because it's currently a heavy WIP
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
<jeromegn>
for the callback stuff, I'm passing around, from Crystal to C, the "const v8::FunctionCallbackInfo<v8::Value>& args" which I think is wrong but somehow works.
qard has joined #crystal-lang
duane has joined #crystal-lang
qard has quit [Remote host closed the connection]
<jeromegn>
According to C, the sizeof that args thing is 24, but in Crystal, if I pad a struct with 24 bytes, it'll segfault, I need to keep it under or equal to 16 bytes for it not to segfault
qard has joined #crystal-lang
<jeromegn>
everything else just works, pretty reliably (didn't do exhaustive testing though)
qard has quit [Read error: Connection reset by peer]
<jeromegn>
this callback stuff is trickier though.
qard has joined #crystal-lang
qard has quit [Read error: Connection reset by peer]
<jeromegn>
my life would be slightly easier if I could expose a Crystal function to C directly and then I'd use that to accept callbacks and parse properly.
qard has joined #crystal-lang
<FromGitter>
<asterite> You can, using `fun`
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
<FromGitter>
<asterite> I'm not sure, but someone else wanted to bind V8 and had troubles, not sure it was because of threads (but it seems to be working for you
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Read error: Connection reset by peer]
<jeromegn>
@asterite: v8 is not thread-safe for most operations, but if you use the "Locker", then you can call it from anywhere.
<jeromegn>
@asterite what do you mean by using "fun"? I can expose a Crystal function to C by doing that?
qard has joined #crystal-lang
qard has quit [Remote host closed the connection]
<jeromegn>
I thought it was for the other way around
qard has joined #crystal-lang
<RX14>
you can write a fun with a body
qard has quit [Read error: Connection reset by peer]
qard has joined #crystal-lang
qard has quit [Read error: Connection reset by peer]
qard has joined #crystal-lang
<jeromegn>
Interesting
qard has quit [Read error: Connection reset by peer]
qard has quit [Read error: Connection reset by peer]
qard has joined #crystal-lang
<RX14>
jeromegn, that's still not a complete runnable example so it's hard to understand what you're trying to accomplish on the crystal side
qard has quit [Remote host closed the connection]
qard has joined #crystal-lang
qard has quit [Read error: Connection reset by peer]
qard has joined #crystal-lang
qard has quit [Read error: Connection reset by peer]
<FromGitter>
<straight-shoota> @alex-kampa put the entire `while` loop in a `spawn do ... end` block
<FromGitter>
<straight-shoota> but you probably want to ensure that the main fiber waits at some point, otherwise the program will exit once the main fiber has reached it's end
<FromGitter>
<alex-kampa> Thanks @straight-shoota it works (had not thought of doing nested spawn...)
<RX14>
@jeromegn, I see FunctionCallbackInfo and lib_v8.cr but there's no top-level code at all
<RX14>
and without that there's no way to see where anything comes from
<RX14>
there actually isn't a single C lib call in your gist
<RX14>
oh nvm
<RX14>
i was looking at the old gist
<jeromegn>
oh, my bad
<jeromegn>
of course there are a ton of other files for Context, Isolate, etc.
<jeromegn>
I guess it might be time for a repository heh
<RX14>
yes
<FromGitter>
<alex-kampa> hey @straight-shoota - if you're still around: what's the best way to send json data structures over tcp/ip?
<RX14>
since when can you not give arguments names in C bindings anyway
<RX14>
I didn't know you could do that
<FromGitter>
<straight-shoota> @alex-kampa Define JSON mapping on you data type and then it's as simple as `data.to_json(socket)` and `DataType.from_json(socket)`
<FromGitter>
<straight-shoota> or if you want to send arbitrary JSON data without mapping: `JSON.build(socket) do |builder| ... end` and `JSON.parse(socket)`
<jeromegn>
oh, I guess I pushed the compiled .o file too hehe.
<RX14>
so
<RX14>
whats wrong?
<RX14>
i don't get all this debug output
<jeromegn>
RX14: :) the pointers are off and that causes segfaults. in the output, the lines starting with "pointer of arg n is" are the pointers I'm getting on the C side. then the log lines like Pointer(Void)@0x7fff00000002 are the pointers I get from the Crystal side. they don't match for the same argument number
<jeromegn>
I expect it has to do with the thing you mentioned first
<jeromegn>
pointer of pointers
<RX14>
wait no
<RX14>
you just put argv on the stack
<RX14>
in the v8_FunctionCallbackInfo
<RX14>
or wait how do you read C types again
<FromGitter>
<ryankshah> How can I pass n functions into a method to be used to produce a result? Say each of these n functions takes a value T and outputs an Int32
<RX14>
ugh
<RX14>
@jeromegn, you allocated argv on the stack
olbat has joined #crystal-lang
olbat has joined #crystal-lang
olbat has quit [Changing host]
<RX14>
you're returning stack memory
<jeromegn>
oh, how did I do that? :D
<RX14>
in v8_FunctionCallbackInfo
<RX14>
you just declare void* argv[argc];
<RX14>
thats on the stack
<RX14>
thats an array of void*, size of argc, on the stack
<jeromegn>
right
<RX14>
you need to malloc that
<RX14>
and just make it a void**
<jeromegn>
oh
<jeromegn>
I can do that
<jeromegn>
:)
<RX14>
malloc(argc* sizeof(void*))
<RX14>
etc..
<RX14>
i could be wrong
<RX14>
i'm not a C++ expert
<jeromegn>
I think that makes sense
<jeromegn>
RX14: would you give me a slightly more complete example? :D I should malloc and then memcpy the pointers onto it?
<RX14>
well I don't even know what a Value is
<jeromegn>
it's a pointer, or something that can be cast to a pointer at least.
<jeromegn>
it's a V8 value made persistent, which just means it's a pointer that stays alive unless you release it
<RX14>
there's too much abstraction and indirection from C here
<RX14>
i hardly know whats going on
<RX14>
and you don't seem to be confident in C++
<jeromegn>
oh I definitely am not
<jeromegn>
learning by doing though
<RX14>
well i'm barely confident in C++
<RX14>
jeromegn, the loop doesn't need to change
<RX14>
just `void **argv = malloc(argc * sizeof(void*))`
<jeromegn>
I get `a value of type "void *" cannot be used to initialize an entity of type "void **"`
<jeromegn>
gonna have to play with it a bit later
<RX14>
just cast it
<jeromegn>
I’ll try that when I get back home. Thanks so much
greengriminal has joined #crystal-lang
<jeromegn>
I wonder how that ever worked in the golang lib. It uses very similar code
<jeromegn>
Ohh, it must be their exported golang C function that managed to get the pointers right
<jeromegn>
I’ll try to export a Crystal function to C later.
<jeromegn>
I’m curious how it works though. It’ll still be allocated on the stack
<RX14>
yes, the code allocates argv on the stack
<RX14>
but it only passes it to the go_callback_handler that it calls
<RX14>
not returns it
<RX14>
stack memory works perfectly for passing down the stack because the caller's stackframe *cannot* be overwritten
<RX14>
you can't pass stack memory up the stack because the caller's stackframe has been cleaned up by the time you reference it
<RX14>
i mean the callee's stackframe
<jeromegn>
Oh right, yes that makes sense
<crystal-gh>
[crystal] sdogruyol closed pull request #6073: Fix background color for dark themes (master...docs-background-fix) https://git.io/vpKYb
<FromGitter>
<asterite> returning structs from C to Crystal might not be working well, beware
<FromGitter>
<asterite> or... I remember someone else having problems with that. The C ABI isn't correctly implemented. It was copied from Rust some time ago, but that changed in Rust, so someone will need to update that
<jeromegn>
@asterite: can you point me to where in the Crystal source I should look for that?
<FromGitter>
<asterite> but it really depends on how and why it's failing for you right now (not sure if you solved it already)
<RX14>
jeromegn, you don't need to return a struct
greengriminal has quit [Ping timeout: 260 seconds]
<RX14>
and you shouldn't need to
<jeromegn>
RX14: oh right yea. I just tried your code and it works 👍
greengriminal has joined #crystal-lang
<RX14>
so i think it's a fairly moot point
<RX14>
my code?
<RX14>
with the malloc?
<jeromegn>
no the crystal function
<RX14>
or with the fun callback
<RX14>
ok
<RX14>
good
<jeromegn>
thanks :D
<RX14>
yes, that's the right approach
<RX14>
i don't think struct return is broken
<jeromegn>
I wonder how it'll behave with threads, I was planning forking my crystal process
<RX14>
i could be wrong
<RX14>
but I don't think it was the problem here
<jeromegn>
yea I don't think it was either
<RX14>
well forks are seperate processes
<RX14>
so
<RX14>
yeah
<jeromegn>
is there something between forks and fibers? :D
<RX14>
i don't know where threads come into it
<RX14>
...
<RX14>
fibers all run in 1 thread
<RX14>
forks aren't threads
<RX14>
or have any of the same rpoblems as threads
<jeromegn>
right, I guess I meant: is there a way to make a thread?
<RX14>
no
<RX14>
well technically yes but it segfaults lol
<jeromegn>
technically a fork will make a new process and therefore it will run in a different thread
<RX14>
instantly
<RX14>
jeromegn, thats like saying systemd and firefox run in different threads
<RX14>
it's true
<RX14>
but completely irrelevant
<jeromegn>
right
<RX14>
you don't need threads afety in v8
<RX14>
for now
<RX14>
until crystal gets paralleism
<jeromegn>
if I use fibers, wouldn't I need to have some sort of mutex? or would that also be fine?
<FromGitter>
<S-YOU> Threads are okay, if you only use C functions :)
<RX14>
jeromegn, fibers all run in the same thread
<RX14>
as far as C is concerned it's all the same
<jeromegn>
interesting
<RX14>
again: until parallelism
<jeromegn>
right
<RX14>
then everything will break
<jeromegn>
sounds awesome
<RX14>
yeah but every other shard will break too
<RX14>
so you can all cry together
<jeromegn>
we'll have support groups
sz0 has joined #crystal-lang
<RX14>
makes me want to just implement smooth IPC with SHM and avoid paralleism
<FromGitter>
<sdogruyol> hey @jeromegn long time no see 👋
<jeromegn>
hey there!
<RX14>
just have a method like pspawn which fork()s and then you have a PChannel which is a normal Channel(T), but uses shm to communicate between forks
<RX14>
and everyone is somewhat happy
<jeromegn>
yes, I mostly come here when I run into issues and then disappear, I'm leeching help, never seeding it.
<jeromegn>
:D
<RX14>
but most improtantly: safe
<RX14>
actually I need to just implement that
<FromGitter>
<sdogruyol> haha, that's okay :D
<RX14>
i feel like i've had an eeexcelent idea
<jeromegn>
RX14: I looked into SHM a few months ago, super interesting concept.
<jeromegn>
:D
<jeromegn>
:doit:
<RX14>
and then just obsolete parallelism entirely
<RX14>
well
<RX14>
largely
<RX14>
it wouldn't be as fast or as flexible
<RX14>
but it'd be super simple to implement (even as a shard)
<FromGitter>
<sdogruyol> @RX14 we need you on Windows :)
<RX14>
wow this is easy
<RX14>
ok
<RX14>
maybe not
<RX14>
but it'll be fun to see what comes out of it
<jeromegn>
I'd love to see that
<RX14>
i can just LibC.mmap(nil, sizeof(T), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS)
<RX14>
in the pchan
<RX14>
and then fork
<RX14>
actually i'd need a semaphore for the pchan
<FromGitter>
<codenoid> crystal is much readable than Python
Totoro- has quit [Ping timeout: 256 seconds]
Totoro has joined #crystal-lang
<FromGitter>
<codenoid> python is cancer
<FromGitter>
<sdogruyol> lol
<FromGitter>
<fridgerator> oof
<FromGitter>
<codenoid> yeah, idk, i got many "error" when coding with python, but not with crystal <3
gizmore|2 is now known as gizmore
<FromGitter>
<sdogruyol> that's interesting
<gizmore>
python? isn't that an esoteric language like whitespace?
<FromGitter>
<bew> RX14 I was thinking about that too fibers & processes, but never tried anything actually. Will you PoC something?
<FromGitter>
<bew> @Blacksmoke16 yes
<FromGitter>
<bew> Those 2 are different types
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<hmans> What is up, Crystal people
<RX14>
badeball, i might make a poc
<RX14>
oops
<RX14>
@bew *
<FromGitter>
<bew> Cool ;)
<FromGitter>
<sdogruyol> good @hmans 👍
<FromGitter>
<sdogruyol> how about you?
<FromGitter>
<bararchy> RX14 sounds interesting to try out , how would that work API wise? Using fibers is seamless, would I automagiclly will get the process-threading thing? Or would you do something like pool.do { code to parallel }
<RX14>
all the shard would do is provide spawn and channels... but between multiple processes
<RX14>
oh actually
<RX14>
i'd have to kill all the other fibers somehow
<RX14>
that'll be fun to do
<FromGitter>
<bew> Oo why?
<RX14>
when you do pspawn you'd fork
<RX14>
but you wouldn't want to take all the fibers with you
<RX14>
you'd want to start a new fiber and close out the other fibers
<RX14>
ugh
<FromGitter>
<bew> Oh right, that would be a flush ib the scheduler in the new process I think?
<FromGitter>
<bew> Flush/reset
<RX14>
i really want to just exec(/proc/self/exe) but with an alternate main here don't I
<FromGitter>
<bew> Why exec... Oh you mean that all the process would start at the beginning?
<RX14>
yeah
<RX14>
but the shm wouldn't survive a real exec
<RX14>
i think
<RX14>
or just use "real" shm_open
<RX14>
the one thing I want and need to do is ensure that the binary used by pspawn is exactly the same as the parent
<RX14>
and I don't think thats possible without fork()
<FromGitter>
<bew> Because of the main?
<RX14>
no because i haven't a clue how /proc/self/exe handles someone just going in and editing the binary
<RX14>
actually you know what
<RX14>
I know how to solve it
<RX14>
fork() in the shard at the start
<RX14>
before anything has a chance to spawn fibers
<FromGitter>
<bew> RX14 but it should be enabled only if I actually need it
<RX14>
a fork() is basically free
<RX14>
you'd just keep one around
<FromGitter>
<bew> (but yeah first poc it, we'll see the details later)
<RX14>
just keep a fork around at the start which then forks off other processes when asked to by children
<FromGitter>
<bew> sounds good
<FromGitter>
<bew> to choose the number of processes it highly depend on the usecase (what the application is doing), so (later!) this should be configurable somehow
<RX14>
uhh
<RX14>
no
<RX14>
i don't think you understand
<RX14>
you can spawn however many processes you want
<RX14>
whaenever you want
<FromGitter>
<bew> oh ok, I thought you meant that it start N processes for N cores or sth
<RX14>
the original fork() would just sleep (on a mutex) until it got a signal to fork again
<RX14>
no
<FromGitter>
<bew> if we have control, then 👌
<RX14>
i meant fork() at the start to keep around a "pristine" process
<FromGitter>
<bew> pristine? "master"?
<RX14>
which you can then fork *again* into more pristine processes to actually do the pspawn in
<FromGitter>
<bew> I like that
<RX14>
oh actually nvm you'd want to carry the object space around
<RX14>
bad idea
<FromGitter>
<bew> not necessarily
<RX14>
well, yes you would
<RX14>
unless you wanted segfaults
<FromGitter>
<bew> if you share memory yes, but if you think the pspawn processes as a usecase for functional style, where you give a copy of the arguments & get back a result you don't need the object space (but that's probably not a good way to think it, now that I rethink about it)
<RX14>
actually removing fibers is unneccesary and would cause deadlocks (maybe)
<RX14>
but I don't think of this as functional style
<RX14>
I want this to be as close to CSP-style but with whole processes as possible
<FromGitter>
<bew> hum, I'd love to see a concept description (if you have time, might be simpler to discuss about it without start the implem')
<FromGitter>
<hmans> @sdogruyol Doing some late evening hackery 🎉
p0p0pr37 has quit [Remote host closed the connection]
p0p0pr37 has joined #crystal-lang
<FromGitter>
<bew> or do both, Crystal is very good for trying things and POCing around :P
<FromGitter>
<codenoid> agree @bew
<FromGitter>
<codenoid> i have more control with crystal,
<FromGitter>
<hmans> Adding an ATOM feed to crankypants... Xml::Builder all the things
<FromGitter>
<hmans> BTW, any plans for doctests in Crystal?
<FromGitter>
<bew> oh testing the snippets in docs, that's fun
<FromGitter>
<hmans> Elixir and a bunch of other languages. Basically, it'll run through your code base's comments, looking for stuff to execute, and run that as a spec.
<FromGitter>
<sdogruyol> yeah, when I first saw that in Elixir..I was pretty impressed
<FromGitter>
<bew> this would mean that code examples should be written as a spec, maybe not possible for Crystal
<FromGitter>
<straight-shoota> and the formatter already formats example codes
<FromGitter>
<hmans> When I have more time later this year, I may have a go at assembling a PR.
<FromGitter>
<straight-shoota> so it shouldn't be to difficult to fit that into the compiler. question is if this *should* be a compiler feature
<FromGitter>
<hmans> @straight-shoota I would expect it to live in `spec`
<FromGitter>
<straight-shoota> or is better off as an individual program
<FromGitter>
<hmans> It could just be a crazy macro.
<FromGitter>
<bew> @hmans but you don't have access to the docs in `specs`
<FromGitter>
<bew> crazy macros are bad for your health :P
<FromGitter>
<hmans> Yes I do: `run_doctests "src/foo/bar.cr"`
<FromGitter>
<hmans> My health is already ruined
<FromGitter>
<hmans> run_doctests would read the file, parse it for comments, etc. etc. etc.
<FromGitter>
<straight-shoota> that's way to complicated
<FromGitter>
<hmans> I'd love to do some experimenting on that stuff. Won't have time until autumn-ish though :(
<oprypin>
sdogruyol, lol python had doctests for like 20 years and now it's just viewed as an obsolete bad practice
<FromGitter>
<straight-shoota> the parser can already parse the docs, so it should be pretty easy to have it turn the example code into spec code
<FromGitter>
<hmans> Serving HTML from the server is now considered a bad practice, so I've kind of given up on listening to people's thoughts on bad practices. :b
<oprypin>
it's just extremely annoying to use doc tests, u know?
<FromGitter>
<bew> @straight-shoota oh yeah, maybe with the `# => expr` and # : Type` comments!
<oprypin>
it's not good for examples (they get too verbose with unnecessary setup) and not good for tests (who wants to indent every line with # and 4 spaces or whatever
<FromGitter>
<hmans> Can I inspect a module's/method's comments at compile or runtime?
<oprypin>
no
<FromGitter>
<hmans> @oprypin It's not an either-or thing.
<FromGitter>
<hmans> Doctests are supposed to complement your spec suite, not replace it.
<oprypin>
did i imply that anywhere?
<FromGitter>
<hmans> At the very least, they prove that the examples in your code are functioning.
<oprypin>
that can be nice
<FromGitter>
<bew> @hmans doctests shouldn't be part of your specs IMO, yeah proving that the examples works are the main usecase to me
<FromGitter>
<straight-shoota> that's the only reason I'd want to have such a thing. There should already be specs for everything covered in examples
<FromGitter>
<straight-shoota> And I think that speaks against integrating it into the compiler or spec suite
<FromGitter>
<straight-shoota> having a separate tool is totally fine to ensure the examples work
<FromGitter>
<bew> 👍
<FromGitter>
<straight-shoota> If you occasionally catch a bug it just means you spec suite is too thin
<FromGitter>
<fridgerator> so then they are like advanced spell checking
<FromGitter>
<straight-shoota> basically a `File.join` for `URI#path`?
<FromGitter>
<hmans> ie. when given an original, fully qualified URI, and another URI, a new URI is returned that represents a "joined" URI depending on whether the second URI was fully qualified or not.
<FromGitter>
<hmans> It's a good opportunity to get the Crystal specs to run on my system... 🅱️
greengriminal has quit [Ping timeout: 255 seconds]
<FromGitter>
<bew> I think you can open an issue about it, see how it goes
greengriminal has joined #crystal-lang
<FromGitter>
<hmans> @straight-shoota here's a general Crystal question: if that had been my code, I would have written two implementations of `relative_url`, one (String) and one (URI), and would have had the former call the latter with the parsed URI
<FromGitter>
<hmans> Is that considered a bad thing in Crystal?
<FromGitter>
<hmans> (I understand it's one more method call, but other than that?)
<FromGitter>
<bew> @hmans it's good
<FromGitter>
<straight-shoota> yeah, it's not much of a difference
<FromGitter>
<straight-shoota> I guess I'd rather have two methods as well. This PR is just a rough proof of concept
<FromGitter>
<hmans> BTW, in Ruby, URI.join is a class method (I was wrong about that earlier), but this is how it behaves:
<jeromegn>
I was pre-compiling them, but seems unecessary now
<FromGitter>
<bew> You should not rely on it though
<jeromegn>
how come^
<jeromegn>
*?
<FromGitter>
<bew> On your system the linker used by Crystal is a full compiler that happen to play like a linker, and we use it like this. But on other system maybe we'll use rhe linker directly, and the linker can't compile your files
<jeromegn>
oh
<FromGitter>
<CImrie> Hey everyone - got a weird issue that I'm sure someone will know how to fix in about 1 second: ⏎ `crystal sam.cr -- db:migrate` ⏎ This is meant to pass 'db:migrate' to the sam.cr file but crystal throws ⏎ `Error: unknown argument db:migrate` which suggests it's being passed to the crystal compiler instead. ⏎ ... [https://gitter.im/crystal-lang/crystal?at=5af213a040f24c430461fdc4]
moei has joined #crystal-lang
<FromGitter>
<girng> is it possible to create a send method for a socket connection, that has a callback that is called, when the server acknowledges the message was received?
<FromGitter>
<asterite> @CImrie I'm pretty sure that error is from the app, not Crystal. If in doubt: `crystal build sam.cr; ./sam db:migrate`
<FromGitter>
<CImrie> Thanks @asterite will give it a go 👍
<FromGitter>
<CImrie> Odd, still the same error!
<FromGitter>
<asterite> Exactly. The error comes from your `sam.cr` app
<FromGitter>
<asterite> No idea what that `sam.cr` is
<FromGitter>
<CImrie> Oh right 😅 If I run crystal sam.cr modified with `puts Sam.pretty_print` it outputs all of the registered commands -- https://github.com/imdrasil/sam.cr ⏎ It's basically a tool for programmatic migration rather than micrate. ⏎ I like the added flexibility that it *should* provide by having access to the full language during a migration. ⏎ ⏎ That said this is a thorn in my side now :P
<jeromegn>
RX14: ok apparently V8 relies on something called "thread local storage" which isn't compatible with fibers. my stuff doesn't work if I try to run some things in a fiber (but if I run *everything* in the same fiber, then it's fine.) for instance, if I store a v8 js function and then try to call it within a fiber, 💥
<RX14>
but
<RX14>
they're the same threads
<RX14>
how does TLS work anyway?
<jeromegn>
yea I'm confused, still trying to read about it
<RX14>
i don't believe you :P
<jeromegn>
haha
<RX14>
because the scheduler is in TLS
<jeromegn>
that I'm reading about it?
<RX14>
and the scheduler is accessed from every fiber
<jeromegn>
mmm
<jeromegn>
I did print the thread id in C and got the same thread inside and outside a fiber
<jeromegn>
but still, something is weird
<jeromegn>
and I'm using the mutex
<jeromegn>
(the V8::Locker) thing
<jeromegn>
sorry, I know you don't know the specifics
<RX14>
well either way
<RX14>
we use ThreadLocal in crystal
<RX14>
from all fibers
<RX14>
and it works
<jeromegn>
I mean, stuff works
<jeromegn>
but any javascript function I try to call will trigger a "Maximum call stack exceeded" error (not in Crystal, an actual JS error)
<jeromegn>
but not if I run it outside a fiber
<jeromegn>
looking it up, most people say this happens if you're not locking right
<jeromegn>
but I am, using the same logic for locking as in golang, which has fibers too (and multiple threads.)
<FromGitter>
<bew> What is needed to make/trigger a release?
<jeromegn>
either you "make" a v8::Unlocker or when the v8::Locker goes out of scope
<jeromegn>
been doing the latter
<jeromegn>
I also tried without the Locker entirely, but there are checks in V8 which didn't let me proceed