<FromGitter>
<Blacksmoke16> better way to get the first line of a string? `string.lines.first`, or some regex, or?
<FromGitter>
<Blacksmoke16> maybe `string.each_line { |l| return l }` to avoid the array of `.lines`?
<FromGitter>
<Blacksmoke16> `.each_line.first` iterator version is prob the winner
ur5us has quit [Ping timeout: 260 seconds]
<FromGitter>
<Afront> @Daniel-Worrall welp, so it's not a good idea using Crystal for embedded development?
<FromGitter>
<smalls12> I think he might have meant natively, cross compiling is easier
<FromGitter>
<smalls12> it looks like the crystal compiler is good enough to get running on embedded
<FromGitter>
<smalls12> or rather, get crystal binaries running on embedded
<FromGitter>
<smalls12> I'm having difficulty getting the compiler built for ARM from my x86 machine
<FromGitter>
<smalls12> he was able to and I am curious how since crystal lacks a bootstrapping method to build
<FromGitter>
<smalls12> you need crystal to build crystal
<FromGitter>
<smalls12> I only just got cross compiling to work now actually ⏎ I was trying to cross compile the crystal compiler, but just needed libcrystal.a ⏎ and didnt realize libgc.a was a completely separate repo lol
<FromGitter>
<smalls12> I wanted to make a webserver on my rpi ⏎ but c++ has too much upfront ⏎ already did it with python somewhere else ⏎ go, despite what people keep saying, I don't find it as easy as crystal [https://gitter.im/crystal-lang/crystal?at=5e8941d09316f34b8d7ef578]
<FromGitter>
<Blacksmoke16> whoa, did error messaging get updated for JSON parsing?
<FromGitter>
<deiv> Hi, about the bootstrap script for building the compiler, is there anyway to reduce the rounds ? or using the first round (from ruby) to build an actual version?
<FromGitter>
<deiv> Im working on packaging crystal inside debian, by the way
<FromGitter>
<deiv> Another question is, I see in the omnibus package the crsytal source installed in /usr/share (i remenber), they are needed for compiling or runtime in any way
<FromGitter>
<deiv> Thanks
<FromGitter>
<stronny> given that Crystal releases often, what's the plan? unstable + backports?
<oprypin>
i hope people won't actually use debian's stale packages 😬
<FromGitter>
<Blacksmoke16> Or use snap, also allows installing nighlies
<FromGitter>
<deiv> @stronny normal releases, if needed backports, but first need to look if its posible to boostrap it without much hustle
<FromGitter>
<deiv> @oprypin thats low blow lol
<oprypin>
deiv, which rounds are you talking about? you just download an official crystal binary and then build your own crystal using that. basically 1 round
<oprypin>
deiv, then to answer your question, no, there is no way to reduce the rounds.
<FromGitter>
<deiv> Maybe
<oprypin>
you could actually try dropping those individual `stage` from the script but it's not gonna be a big win
<oprypin>
even if a few of them are unnecessary
<oprypin>
I'm guessing towards the end some of the releases are not necessary and are included just for completeness
<oprypin>
oof. on arch linux i'm getting this error consistently now. `.build/all_spec: symbol lookup error: .build/all_spec: undefined symbol: __libc_start_main` for `make clean; make && make spec`
<FromGitter>
<smalls12> did the `./build/crystal` target work ?
<FromGitter>
<smalls12> I had some issues yesterday
<oprypin>
i think it works, it's specific to spec because it's so big
<FromGitter>
<stronny> @deiv until 1.0 Crystal changes sometimes even breaking API, so maybe you could package each version into its own package? like `crystal-0-33` or something
<FromGitter>
<stronny> people are looking for older version quite often and there is an explicit version lock in shards.yml as well
<FromGitter>
<Blacksmoke16> what the `crystal: 0.33.0` thing?
<FromGitter>
<stronny> yeah
<FromGitter>
<Blacksmoke16> that doesnt do anything
sagax has quit [Read error: Connection reset by peer]
<FromGitter>
<stronny> it should
<FromGitter>
<Blacksmoke16> i agree, but it doesnt atm
<FromGitter>
<stronny> still, my point stands
<FromGitter>
<Blacksmoke16> is just a way to represent the last known version a shard works with
<FromGitter>
<Blacksmoke16> but its not enforced or anything and is up to the owner of the shard to keep up to date
<FromGitter>
<stronny> that's unhelpful model being "we only have the most recent supported version available, and if you somehow end up with broken code well good luck"
<FromGitter>
<stronny> I agree with breaking changes, at least there should be a way to roll them back if the need arises
<FromGitter>
<stronny> by the way I don't understand this universal race to 1.0
<FromGitter>
<stronny> what's gonna change? you alread have a stable API: just get the right version, it won't change on you suddenly by itself
<FromGitter>
<Blacksmoke16> :shrug:
return0e_ has quit [Ping timeout: 256 seconds]
<FromGitter>
<deiv> @stronny it could go without versioning and people install the one who wants
<FromGitter>
<deiv> On other way, the source files (*.cr for compiler and std) are needed for compiling runtime?
<FromGitter>
<deiv> Compiling or runtime**
MasterdonX has quit [Ping timeout: 256 seconds]
MasterdonX has joined #crystal-lang
return0e has joined #crystal-lang
Subsentient has joined #crystal-lang
<Subsentient>
So, how far off is Crystal from Windows support? I love what I'm seeing, but most of the development I do needs to be somewhat portable.
deavmi has quit [Quit: Going into the wilderness...]
deavmi has joined #crystal-lang
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
ht_ has joined #crystal-lang
_ht has quit [Ping timeout: 260 seconds]
ht_ is now known as _ht
<oprypin>
Subsentient, biggest gap is networking. other than that, u can mostly use it. compiler itself doesnt run on windows but oh well
sagax has joined #crystal-lang
<FromGitter>
<stronny> wsl?
<FromGitter>
<naqvis> quick question: what is the right way to pass primitives to FFI expecting input as `void*`? Tried `pointerof` but seems FF is receiving invalid value.
<FromGitter>
<asterite> are exceptions already working in Windows?
rohitpaulk has quit [Ping timeout: 265 seconds]
ur5us has joined #crystal-lang
rohitpaulk has joined #crystal-lang
<oprypin>
asterite, yes. well actually not sure, stack traces didnt look so good last i checked. @RX14's work, of course
rohitpaulk has quit [Ping timeout: 256 seconds]
<Stephie>
exceptions work pretty well
<Stephie>
backtraces are different
<Stephie>
backtraces require debug info and a library to decode it
<Stephie>
remember we literally implement a DWARF parser on linux and macos for this
<Stephie>
windows, of course, uses something special and unique
<Stephie>
actually i dont think we even have libunwind working
<Stephie>
:/
<Stephie>
difficult...
<Stephie>
oh wow
<Stephie>
libunwind doesnt use libunwind at all
<Stephie>
amazing
<Stephie>
i give up
_ht has quit [Remote host closed the connection]
_ht has joined #crystal-lang
<yxhuvud>
How do other languages solve that?
<Stephie>
requires research
<FromGitter>
<stronny> golang solves that by not having exceptions
<FromGitter>
<stronny> does it unwinds panics?
<Stephie>
it can
<Stephie>
optionally
<Stephie>
there's an env var iirc
<Stephie>
or maybe thats rust
<raz>
hmm. when i have: def foo(klass : Bar.class). can i somehow make it accept also any sub-type of Bar? (e.g. it should accept Batz.class, when Batz is defined as "class Batz < Bar")
<FromGitter>
<stronny> yeah, it should
<FromGitter>
<stronny> have an example where it doesn't?
<raz>
ah gtk that it should. hmm gonna try to create a minimal example then. perhaps my problem stems from something else and i just got lost in the type magic
<FromGitter>
<perfecto25> hello everyone, quick question, how do i pretty print a JSON object?
<FromGitter>
<perfecto25> i have a function that returns a JSON, 1 liner, wanted to pretty print it out
<FromGitter>
<stronny> all the method defs are macros
<Stephie>
uhh
<Stephie>
no?
<FromGitter>
<stronny> yes
<Stephie>
where??
<FromGitter>
<stronny> ask ary
<Stephie>
well if thats what you understood from ary then you don't understand what he said
<Stephie>
defs are very different to macros and you know it
<FromGitter>
<stronny> maybe I didn't
<Stephie>
defs are instantiated for every set of argument *types*
<Stephie>
macros are instantiated always
<FromGitter>
<stronny> why does it matter?
<Stephie>
because people overuse macros in persuit of "maximum DSL beauty" and end up with brittle DSLs which shatter when you hold them slightly wrong
<FromGitter>
<stronny> ```def foo(*args); end```
<Stephie>
or end up not being able to handle unusual usecases
<Stephie>
okay, after i rewrote the entire optionparser
<Stephie>
oprypin, how do you mean?
<oprypin>
Stephie, well if one wants Process support on Windows, they could choose either of those two as the starting point, and your seems more idiomatic
<Stephie>
it's been so long
<oprypin>
yes
<Stephie>
i remember looking at both and going like
<Stephie>
"well they're not so far off the difference is mostly style"
<Stephie>
damn the windows process file is like twice the size on the new PR
<Stephie>
oprypin, if you have the will to bring that commit up to date, please,,
<Stephie>
it's better than that PR, but
<Stephie>
i just dont have the energy to care any more
<oprypin>
welp, yes, that's the current plan
<Stephie>
thanks
<Stephie>
it's really appreciated
<Stephie>
yay, more people to add to the "burnt out over adding windows support" pile of bodies
<oprypin>
it's cursed :3
<Stephie>
definitely :3
<Stephie>
at least i trust you to have a sense of style
<oprypin>
aw, thanks.
<Stephie>
...did macos CI fail in your PR because circleci tried to run it in the context of your fork oprypin??
<Stephie>
thats so broken
<FromGitter>
<deiv> @RX14 stupid question hehe should the bootstrap-script works without touching anything ?
<oprypin>
Stephie, yea i think so
<Stephie>
lol
<Stephie>
@deiv which bootstrap script? For windows?
<Stephie>
what do you mean by "touching anything"?
<Stephie>
it's certified working on my machine a year ago
<FromGitter>
<deiv> without change any line of code ... mostly from bash
<Stephie>
which means... approximately nothing
<Stephie>
@deiv try it...
<Stephie>
it *should* be fairly robust
<FromGitter>
<deiv> im having linking problems
<Stephie>
okay
<Stephie>
that sounds, about right
<Stephie>
can you show me?
<FromGitter>
<deiv> lots ot them xD
<FromGitter>
<deiv> for example /usr/bin/ld: /home/deiv/dev-dinamic/debian/pkgs/crystal/bootstrap-script/buildroot/llvm33/lib/libLLVMSupport.a(Errno.o): en la función `llvm::sys::StrErrorabi:cxx11 (int)': ⏎ Errno.cpp:(.text+0x6b): referencia a `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' sin definir
<FromGitter>
<deiv> in round 3
<Stephie>
oh god
<Stephie>
if llvm33 doesnt build thats pretty cursed
<FromGitter>
<deiv> if I add "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr"
<FromGitter>
<deiv> to it
<FromGitter>
<deiv> I get some ld problems asking for lpthread
<Stephie>
could you send me a pastebin/gist/whatever of the build log?
<FromGitter>
<smalls12> probably cuz it reached eol
<Stephie>
everything rots, nothing is free from decay and death
<FromGitter>
<deiv> :D
<Stephie>
anyway, im glad you found a good workaround for some of those linking errors
<Stephie>
i'd rather that, you know, LLVM actually worked out of the box
<Stephie>
without being cursed
<FromGitter>
<smalls12> llvm-3.3, could you use a newer version ? ⏎ ( just observing in the background here ;p )
<FromGitter>
<kingsleyh> Evening
<Stephie>
@smalls12 nope, that crystal version supports only that old LLVM version
<Stephie>
LLVM versions have breaking changes
<Stephie>
so it's difficult to upgrade
<Stephie>
using something with a sane toolchain like arch linux might still build
<FromGitter>
<deiv> @RX14 so... this thing will never be updated, I guess ...
<Stephie>
I could try it again
<FromGitter>
<smalls12> would it be better in the long run to make it work with newer llvm ? what kind of estimate would you think it would take ?
<FromGitter>
<deiv> Im looging for a way to build crystal without crystal ... but the build depends are very outdated for what I need it
<Stephie>
what's the usecase?
<Stephie>
fun?
<oprypin>
smalls12, would it be better in the long run to port every past version of Crystal every time a new version of LLVM comes out? no, probably not
<FromGitter>
<deiv> @RX14 packaging into debian without uploading a previous binary build of crystal
<Stephie>
you're part of debian packaging team?
<FromGitter>
<smalls12> I understand, but its several major revisions behind, not worth it everytime I agree
<FromGitter>
<deiv> @RX14 what team ? Im on my own, atm ...
<Stephie>
oh
<Stephie>
so this isn't an effort to get it into debian as an official package?
<FromGitter>
<deiv> yes yes, official would be :)
<Stephie>
ah
<FromGitter>
<deiv> and the other user case is to use the bootstrapped binaries rather than the prebuilt ones (if I built crystal from source uploading previously a binary package)
<FromGitter>
<deiv> so, getting a bootstrap script with using only actual libraries (llvm8, ruby2-x, etc) is something "imposible" ? I guess ...
<Stephie>
yes
<Stephie>
it's impossible
<Stephie>
the only other avenue for a clean bootstrap is to write another crystal compiler
<Stephie>
or interpreter
<Stephie>
it wouldn't be *terrible*, just pretty hard
<Stephie>
okay
<Stephie>
it'd be terrible
<Stephie>
and pretty hard
<FromGitter>
<deiv> lol
<FromGitter>
<deiv> and getting the current one working ? :)
<FromGitter>
<deiv> that way could build a crystal compiler without use a precompiled one
<Stephie>
well
<Stephie>
i'll see if it works on arch linux
<FromGitter>
<deiv> thanks !
<Stephie>
if it does, then i can solidly blame debian's build environment
<FromGitter>
<deiv> ok :)
<FromGitter>
<deiv> hehe
<Stephie>
well
<Stephie>
or maybe my non-portable script
<Stephie>
if you can figure out what's the root cause of the link errors i can know who to blame :P
<FromGitter>
<deiv> If I add "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr" I get: /usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error al añadir símbolos: DSO faltante desde línea de orden
<Stephie>
what's that in english >_<
<FromGitter>
<deiv> in round3
<Stephie>
wait
<FromGitter>
<smalls12> would there ever be a need to update that compiler? ⏎ or in its current state, should be more than sufficient for the some time to come
<FromGitter>
<deiv> maybe it needs -lpthread.
<FromGitter>
<deiv> ?
<Stephie>
is this with *debian's* llvm-3.3??
<FromGitter>
<deiv> not
<Stephie>
yeah it probably does need -lpthread
<FromGitter>
<deiv> the downloaded onw
<FromGitter>
<deiv> one
<Stephie>
are you sure there's no /usr/lib<whatever debian shit uses>/libLLVM-3.3.{so,a}??
<FromGitter>
<deiv> no, I have llvm{8,9}
<Stephie>
huh
<Stephie>
interesting
<Stephie>
i wouldnt have expected it to work
<Stephie>
since the script simply tells the compiler where llvm-config is
<FromGitter>
<deiv> stage3 without "sed -i 's/\`llvm-config --libs --ldflags\`/LLVM-3.3/' src/compiler/crystal/llvm.cr" can't find nothing I guess
<Stephie>
this is somewhat disturbing
<FromGitter>
<deiv> remember the gist :D
<Stephie>
yeah
<Stephie>
well
<Stephie>
i'll figure out wtf i was thinking 2 years ago tomorrow :)
<Stephie>
I'll probably boot a debian container and try it
<Stephie>
is this debian stable or debian unstable @deiv ?
<FromGitter>
<deiv> dont blame much then
<FromGitter>
<deiv> testing/unstable/experimental
<Stephie>
oke
<Stephie>
i'll try it in a sid container tomorrow i guess
<FromGitter>
<deiv> testing having pirority (so i thiun testing woud be the guess)
<FromGitter>
<deiv> I will ask you again tomorrow I guess :D
<FromGitter>
<smalls12> out of curiosity, what are you doing with buildroot ?
<FromGitter>
<smalls12> are you trying to cross compile crystal ?
<Stephie>
this isnt actually buildroot
<Stephie>
this is a folder called buildroot
<Stephie>
which i use as a prefix for building stuff in
<FromGitter>
<smalls12> ah ok
<FromGitter>
<deiv> @smalls12 blame @RX14 for her dirs-shit ;)
<Stephie>
completely unrelated to the buildroot project which i was probably unaware of at the time
<Stephie>
hah
<Stephie>
yeah please do :P
<FromGitter>
<smalls12> : )
darkstardev13 has quit [Read error: Connection reset by peer]
darkstardev13 has joined #crystal-lang
<Stephie>
@deiv well i'm up to crystal stage 17 so it seems to only appear on debian
<Stephie>
i'll work out why tomorrow
<FromGitter>
<deiv> @RX14 thanks (the only thing that comes to mind is that here we have multiarch "/usr/lib/x86_64-linux-gnu/" <- all arch specific libs go there)
<Stephie>
llvm-config from LLVM 3.3 sucks
<Stephie>
it just always prints the static library names
<Stephie>
i dont want this, print the .so name please
<Stephie>
i dunno why static linking isnt working either way but
<Stephie>
probably because it's trying to use the system LLVM*.a libs, actually
<Stephie>
cause they have preference over the -L/whatever that llvm-config adds