<FromGitter>
<cbortz> Hey y'all! I have a question about the shards.yml file in projects. What exactly is the `:crystal` property used for? My assumption was that it would somehow require that version of crystal, but the amber project has the value set to 0.33.0 when the version 0.34.0 is actually used. Also, I could install the shards just fine on my machine even though I don't have version 0.33.0 installed. Can someone explain what
<FromGitter>
... this property is actually used for?
alexherbo2 has joined #crystal-lang
<FromGitter>
<naqvis> afaik that shows the version of crystal which was used to develop
<FromGitter>
<naqvis> like when you create new app/lib via crystal cli it will use current crystal version for that property
<FromGitter>
<cbortz> So almost as if the intent is to be informative rather than prescriptive? Am I understanding that correctly?
_whitelogger has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #crystal-lang
<oprypin>
@cbortz: you say "known to work with this Crystal version". it is not used.
alexherbo2 has quit [Ping timeout: 258 seconds]
<oprypin>
there is also an extlibs field that is not used
<oprypin>
oh woops that's "libraries", not "extlibs"
<raz>
speaking of shard.yml, it would be nice if the 'version' could be fetched programmatically so i don't have to maintain it in two places (shard.yml & version.cr)
<raz>
(or the other way round like in ruby, where you can just reference code-consts in the .gemspec, but not sure if that's feasible)
<oprypin>
yea wouldn't it
<oprypin>
which one will it be, requiring compilation of Crystal code to get the version for shards *or* requiring libyaml to get the version for runtime
<raz>
i'd say requiring libyaml but only in the compiler, so it can parse at a compile time and embed the version string :)
<raz>
otoh, i don't even need the shard version in app-code very often. it's just there by default (create by `crystal init`), so feels like it wants to be maintained
<oprypin>
yea
<jhass>
I mean you could just regex it out
<jhass>
or probably even have little handparser to avoid libpcre
alexherbo2 has joined #crystal-lang
<raz>
yup, it should be fairly easy. just feel like that should/could be something in crystal itself. otherwise everyone has to think about it / solve it in a different way
<raz>
(in fact, perhaps version.cr could just be auto-generated with such a macro instead of a fixed string?)
<raz>
ah, well, that would being the yaml dep into every project tho, i suppose
* raz
needs more coffee
<oprypin>
no no no that exact thing was already proposed and thankfully shot down
<oprypin>
the only way to do this is to enforce version.cr being "trivial" with a tiny subset of Crystal parser
<FromGitter>
<galvertez> well kind of my point was that `OpenSSL::SSL::Server` isn't actually anywhere in docs or in code, but i have used it as a socket before, so i am pretty sure it's not an ssl context
<FromGitter>
<galvertez> that is, i did not even realize until checking docs that it should be `OpenSSL::SSL::Socket::Server` rather than `OpenSSL::SSL::Server` - i just guessed, and it worked, so i didn't read much into it lol
<FromGitter>
<galvertez> but i got even more confused when i tried the same thing w/ the client socket, and that didn't work.
<FromGitter>
<galvertez> i am actually hugely surprised that `OpenSSL::SSL::Server` doesn't throw a compile errorr. i seriously can't find that constant anywhere
<FromGitter>
<galvertez> it's less surprising that `OpenSSL::SSL::Client` does throw an error :)
<FromGitter>
<jwoertink> so like in a scenario like this
<FromGitter>
<jwoertink> let's say the tempfile was created without the block, then it would be up to the user to close the file before the action is completed, right?
<FromGitter>
<jwoertink> Actually, that just gave me an idea
<FromGitter>
<watzon> Well they'd just have to close it at some point, or they can keep it open. The file will be closed by the OS on exit, so if it doesn't get closed it's not the end of the world, but it will be using unnecessary memory.
<FromGitter>
<kinxer> Also, I think there's a maximum number of files you can have open at one time, which will cause a runtime exception (and probably crash your program).
<FromGitter>
<watzon> Yeah for sure. So if you're opening and writing to files in a loop it can cause issues.
<FromGitter>
<jwoertink> Yeah, that makes sense
<FromGitter>
<kinxer> Or if you just have a bunch of instances that have open tempfile instance variables.
<FromGitter>
<didactic-drunk> `GC`will also close files. You can't count on it except for one off uses because of the os limit @kinxer mentioned.
<FromGitter>
<kinxer> You could also store the path to the file. That might be more stable, but I don't know what kind of guarantees you have that the OS will keep the file around.
<FromGitter>
<kinxer> I admittedly don't know much about how the OS treats temporary files.
<FromGitter>
<didactic-drunk> @kinxer It doesn't.
<FromGitter>
<didactic-drunk> Temp files are handled purely by the `Tempfile` class. If `close` or it's `finalizer` isn't called it doesn't get deleted.
<FromGitter>
<didactic-drunk> Oh whoops, I'm thinking of ruby.
<FromGitter>
<kinxer> Crystal won't delete a tempfile on close, right? That seems unuseful.
<FromGitter>
<Blacksmoke16> would want to call `.delete` on it when you're done
<FromGitter>
<didactic-drunk> @kinxer That behavior seems bug like.
<FromGitter>
<didactic-drunk> I expect `close` to delete.
<FromGitter>
<kinxer> Why? How would you use a temporary file that was deleted when you closed the file descriptor?
<raz>
you rewind before closing it
<FromGitter>
<kinxer> No, I'm asking what the point is. Would it only be for other programs to read while your program just holds onto a file descriptor for no reason until it wants to stop holding onto it?
<raz>
it's good practice to not leave temp files behind (temp space is finite)
<FromGitter>
<kinxer> I mean, yeah. But I don't see why you'd need the file descriptor to be open the whole time the temporary file is in use.
<FromGitter>
<kinxer> Or, rather, the whole time you want the temporary file to be available.
<raz>
well, that's kinda the definition of a temp file. it exists while you use it, then disappears
<raz>
if the runtime doesn't delete it on close it would have to keep track of them, delete them at_exit, etc.
<raz>
would be more complicated, less reliable
<raz>
plus if you create many or large ones and your process is long running, you could accumulate a lot of cruft
<FromGitter>
<kinxer> Sure. I just still don't get what the use case is for a temporary file that you can never close the file descriptor for until you're done with it. I think the way it currently seems to implemented ("It is encouraged to delete a tempfile after using it" using `#delete`) makes sense; you can choose to keep track of it without holding on to open file descriptors if you needs lots of temporary files.
<raz>
well, i think the main benefit is that it's harder to forget to delete it
<raz>
common use case is write temp file, spawn sub-proc that reads it (all in a block so you don't have to remember closing or deleting it)
<raz>
that close/delete part is often done wrong, (e.g. no ensure for when exceptions are raised)
<raz>
and then you get in trouble with the angry sysadmin who's annoyed cause your little thinger ate up all his /tmp
<FromGitter>
<kinxer> What kind of data would you write to a file and read in a fiber that you wouldn't rather just keep in memory? Or by "sub-proc" are you referring to some other program that you may or may not have written?
<raz>
yup, the latter
<raz>
user uploads image, you feed it to imagemagick or such
<raz>
or if you're exchanging large data between fibers there could also be cases where a temp file is helpful
<FromGitter>
<kinxer> Okay, yeah. I think I get it now.
<FromGitter>
<kinxer> I think I'd prefer a way to clearly mark that you want a tempfile you're instantiating to delete on close rather than just changing the behavior (or even changing the behavior but allowing the current behavior with a clear option).
deavmi has quit [Quit: Eish! Load shedding.]
deavmi has joined #crystal-lang
<raz>
ah yup, a breaking change could surprise people in a bad way
<raz>
i think the current way mirrors go-lang behavior
<raz>
whereas python/ruby/others delete-on-close by default
_ht has quit [Quit: _ht]
deavmi has quit [Quit: Eish! Load shedding.]
deavmi has joined #crystal-lang
hamoko[m] has joined #crystal-lang
HumanGeek has quit [Ping timeout: 246 seconds]
HumanGeek has joined #crystal-lang
HumanGeek has quit [Read error: Connection reset by peer]
<oprypin>
hold up. so we have `Iterator.of` and it seems to be a way to turn a yielding function into an iterator. why do people not know about this?
<jhass>
because it causes segfaults? :D
<jhass>
also no docs
<jhass>
Ah, no it's not like Enumerator.new
<jhass>
it just tkes a block/proc and calls it for each next
<jhass>
so it's just defining an iterator with a simple next body
<jhass>
proper enumerator the block yields all the values
<jhass>
at once
deavmi has quit [Quit: Eish! Load shedding.]
<jhass>
and the enumerator suspends it inbetween
<jhass>
so yeah, there's some overlapping usecases given you can pass a closured block. But not exactly the same
deavmi has joined #crystal-lang
<oprypin>
jhass, well it's not exactly, but with the fact that it's a closure you get pretty close. so like it covers the use case where you would've written `def foo; some_initialization; while true; some_logic; yield stuff; break if condition; end; end`
alexherbo2 has quit [Ping timeout: 260 seconds]
HumanG33k has joined #crystal-lang
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<straight-shoota>
any thoughts on naming a HTML sanitation shard? I went with `sanitize` so far...
<oprypin>
jhass, well what do you know, they do expose the thread data, undocumented json key parentId. https://bpa.st/RKYA - . but uhhh doesn't mean i'll actually do anything about it. realistically do you think people will bother including a thread id in irc
<FromGitter>
<Blacksmoke16> Probably a fine name given its purpose
<FromGitter>
<Blacksmoke16> @straight-shoota its okay that `LIBRARY_PATH` for libgc is overridden in the build image?