<FromGitter>
<wyhaines> @oprypin if the tl;dr was to me, no need to read it. I'm just asking about whether there is any support in Crystal at this time for spawning a process under a pty. ⏎ ⏎ It appears that the answer, unfortunately, is "no".
<FromGitter>
<wyhaines> Which means that the next question becomes -- how badly do I want to write it myself?
_whitelogger has joined #crystal-lang
oddp has quit [Ping timeout: 260 seconds]
<FromGitter>
<dscottboggs_gitlab> @j8r do you maintain https://hub.docker.com/r/jrei/crystal-alpine? It's now 4 versions behind, is the project abandoned or is there something blocking progess?
<FromGitter>
<Blacksmoke16> Why not just use the official one now?
<FromGitter>
<Blacksmoke16> It's kinda redundant no
<FromGitter>
<dscottboggs_gitlab> Oh I see, thanks
<FromGitter>
<Blacksmoke16> 👍
f1reflyylmao has joined #crystal-lang
f1refly has quit [Ping timeout: 260 seconds]
_whitelogger has joined #crystal-lang
<FromGitter>
<watzon> Discovered an interesting thing today: ⏎ ⏎ ```server = TCPServer.new(host, 0) ⏎ port = server.local_address.port ⏎ server.close ⏎ port``` ⏎ ⏎ quick and dirty way to get a random open port. Anyone know of a better way? [https://gitter.im/crystal-lang/crystal?at=5ef03111c4bdd83475fa42af]
_whitelogger has joined #crystal-lang
<FromGitter>
<wyhaines> @watzon That's basically the technique. Passing a port of 0 causes the kernel to allocate the random port. I do not think that there is a way to just ask the kernel for that random port number, though.
<FromGitter>
<watzon> That's unfortunate since time and resources are definitely being wasted creating and destroying a new TCPServer instance, but it's cool that you can do this to get a new random port.
<FromGitter>
<Daniel-Worrall> Why would you need to know an open port? There's no guarantee between asking and assigning it that it'll still be available
<FromGitter>
<watzon> Very small chance it would be taken in the couple milliseconds it takes to find an open port and start a service running on that port. I need to be able to find a random open port so I can start a separate process running on that port and know what port its running on. I could potentially also start the service using `Process.new` and use some regex to find what port it's running on based on the output, but I'd
<FromGitter>
... need a different regular expression for each of like 8 different backends.
<FromGitter>
<watzon> This is for webdriver
_whitelogger has joined #crystal-lang
<raz>
watzon: race condition, don't do it
<raz>
bind the port when you actually intend to keep it, then communicate it back to whoever needs to know it
<raz>
also picking a random port isn't a good idea. if the range can't be constrained it may pick a port that the user wants to use while your proc is running (e.g. "dev server fails to start while tests are running")
<jhass>
oprypin: sorry, not sure I follow
<oprypin>
ffffffjhass: uh well remember how we changed to `ArgType.indirect(t, nil)` from `ArgType.indirect(t, LLVM::Attribute::ByVal)`? that breaks codegen in the case of callback even though it makes things work for calling C code
<oprypin>
"callback" being just a `fun` written in Crystal intended to be called from C
<jhass>
weird
<jhass>
why would it
<oprypin>
jhass: then see the linked diff, the red parts are what Crystal shouldn't be generating in that case (later i found that it's directly due to not using byval)
<oprypin>
so, either there needs to be a way to choose a different kind there depending on the situation or perhaps there is a kind like that already that matches both behaviors in different cases
<oprypin>
by "kind" i mean indirect+byval, direct, etc
<jhass>
but why is it different cases?
<jhass>
why would C expect to be called differently than it expects to be called?
<jhass>
eh, than it does call itself I mean
<jhass>
sorry, not fully awake yet :P
<oprypin>
jhass: uh yes that's a natural thought to have but it doesn't directly follow from this
<oprypin>
it could just mean that this "kind" has different meaning already
<oprypin>
what does `nil` mean anyway, is it some kind of "default"?
<jhass>
pretty sure it is, the call already is "make_indirect" (read pass indirectly)
<jhass>
(read don't pass via registers)
<jhass>
what would a third mode be?
<jhass>
you push the entire value on the stack, or a pointer to it
<oprypin>
with byval everything is good if only you just drop the word "byval" from the generated ll :D
<jhass>
well, I have no idea
<FromGitter>
<naqvis> @msa7 from which version you upgraded to latest version? Former `Logger` module was *deprecated* in version `0.34.0`. So if you code was working in prior versions of Crystal, then you will have to update that Logging code
<FromGitter>
<naqvis> `0.35.0` introduced other breaking changes to Logging which was introduced in `0.34.0`
<FromGitter>
<naqvis> so code developed in versions prior to `0.34.0` is definitely not going to run, without making changes to Logging code
<FromGitter>
<msa7> @naqvis I use 0.34 before upgrade, all was good. I do not use `Logger` in my code. I rolled back to 0.34, project compiled again
<oprypin>
msa7, is it possible to share the entirety of your code
<FromGitter>
<Daniel-Worrall> It's lazily instantiated. It's possible it's being accessed directly without the getter
<FromGitter>
<Daniel-Worrall> Or it's a compiler error with the getter
<oprypin>
what..
<FromGitter>
<Daniel-Worrall> It's being passed a block meaning it's billable
<FromGitter>
<Daniel-Worrall> Nilable
<oprypin>
no
<oprypin>
and do you see Array(String) involved anywhere there?
<oprypin>
jhass, curious to see how aarch64 support would cope with https://bpa.st/CG7Q - because it's possible that the change to `nil` broke this case
sagax has joined #crystal-lang
<oprypin>
oops dont need line 7
<FromGitter>
<Daniel-Worrall> Hmm true
<jhass>
oprypin: I'll check later, gotta work a bit :)
<oprypin>
jhass, ah damn i forgot, it has this ([2 x i64] case for size <= 16 (which it happens to be)
HumanG33k has quit [Remote host closed the connection]
<oprypin>
*maybe* adding a 3rd strucct member would trigger this
HumanG33k has joined #crystal-lang
<jhass>
yeah it does
<jhass>
dammit
<oprypin>
wow nice!! :D :D :D
<jhass>
does it happen on x86_64 too?
<oprypin>
jhass, no
<jhass>
hrm
<jhass>
why not? just uses more registers?
<oprypin>
huh everything is completely different there
<jhass>
maybe
<oprypin>
"uhh"* not "huh"
<jhass>
well I take it you gonna fix it for win64 and that should drive by fix it for aarch64 :P
<oprypin>
jhass, 😬 looks doubtful, i was thinking the other way 😂
<jhass>
maybe the code you linked must just move into the CABI abstraction and be a noop for ours? idk
<jhass>
or it should check whether it's passed indirect rather than byval?
<jhass>
I just don't understand this yet very well :(
<oprypin>
jhass, i really have no idea. all i know is the behavior should be exactly as in the `byval` case, but without actually setting the `byval` attribute
<jhass>
could try how much breaks if you make it check arg.kind.indirect? instead of !by_val?
<jhass>
or however you get access to ArgType in there
<jhass>
uh, check !indirect? I guess
<oprypin>
i tried some things and so far it just makes everything crash entirely
<jhass>
I'm still a bit lost
<jhass>
:(
<oprypin>
good idea tho, i'll try that one
<jhass>
Ary's right though, we should just drop LLVM and transpile to C xD
<frojnd>
If let say token expires after 1 months.. Is there a way I could reqrite .env file with new token programatically? So inside web page? Or is this not designed in that way?
<FromGitter>
<Blacksmoke16> does the token originate from an oauth flow?
<frojnd>
I don't know... in curl command I jsut call --header 'Autorization: '"$TOKEN"'' \
<frojnd>
Authorization*
<FromGitter>
<Blacksmoke16> right, but where did you get the token in the first place?
<frojnd>
Passed through communication channel like irc?
<frojnd>
Don't know how it was generated..
<FromGitter>
<Blacksmoke16> ah ok
<frojnd>
I can ask..
<frojnd>
Not sure when I will get the answer though
<FromGitter>
<Blacksmoke16> prob easier to just manually reexport the var imo
<frojnd>
Oh also one token I copy paste from web network dev tools...
<frojnd>
For another call...
f1reflyylmao has quit [Quit: bye fags]
f1refly has joined #crystal-lang
<FromGitter>
<Blacksmoke16> i wouldnt try to overcomplicate it
<frojnd>
I'm building somesort of monitoring tool which consists of logging serial port, calling bunch of different endpoints and making some sort of logic in case status changes etc.. was starting with bash but for fun will try in crystal
<frojnd>
Where does ENV["PORT"] || "300" writes to? On my Linux system I can define env in different files like ~/.xinitrc but where exacly would that command write on Linux system if at all?
<frojnd>
...Just wondering
<FromGitter>
<Blacksmoke16> what do you mean "write to"?
<jhass>
It does not write at all, it just reads
<frojnd>
What I really love as a newcomer is those helpful error messages... Almost if it know what I meant and made a wrong sequence... just amazing.. Error: the syntax for an argument with a default value V and type T is `arg : T = V`
<FromGitter>
<Blacksmoke16> are you using `URI` anywhere? seems to be related to that. Might also be worth upgrading to `0.35.1`
zorp_ has quit [Ping timeout: 256 seconds]
<FromGitter>
<roduquen> Yes I use the 0.35.0 version but it s never called
<FromGitter>
<Blacksmoke16> dont suppose you can make a smaller example that reproduces the issue?
<FromGitter>
<roduquen> the program crash before calling the function in which those lines are written
<FromGitter>
<roduquen> it s when there is the hashes are not the same type but only in this file
<FromGitter>
<roduquen> when hashes are Hash(String String) and Hash(String Int32)
<FromGitter>
<watzon> > *<raz>* also picking a random port isn't a good idea. if the range can't be constrained it may pick a port that the user wants to use while your proc is running (e.g. "dev server fails to start while tests are running") ⏎ ⏎ The user also has the ability to pick a port if they want to. Random choosing is just there for if they don't pick a port explicitly.
<FromGitter>
<Blacksmoke16> yea i dunno, without a reproducible example there isn't much we can do
<raz>
watzon: ah ok, that sounds better. :) still seems like a questionable default to me tho - why not default to a high port that the user can easily override?
<FromGitter>
<watzon> Defaulting to a set port won't work, because they may start any number of these services and I can't have them all trying to use the same port
<FromGitter>
<watzon> It's pretty common with webdriver libs to have it choose a random port for you
<FromGitter>
<Blacksmoke16> seems to be what you want?
<FromGitter>
<watzon> Seems like it basically does what I'm already doing underneath
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<watzon> Uses `0` as a port and lets the kernel pick an unused one
alexherbo24 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 240 seconds]
alexherbo24 is now known as alexherbo2
svipal has quit [Remote host closed the connection]
gangstacat has quit [Ping timeout: 272 seconds]
rocx has quit [Ping timeout: 260 seconds]
<FromGitter>
<wyhaines> Yeah. That's really the only way to do it. You punt to the kernel and see what it gives you. ⏎ ⏎ You could do other, heavier weight things. You can scan all of the ports that are in use, and then write your own code to pick from what isn't in use, but unless you really need that level of selection control, it's a lot easier to just do what you are doing now.
<FromGitter>
<watzon> Yeah scanning ports seems like an unnecessarily heavy thing
robacarp has quit [Quit: robacarp]
<FromGitter>
<thelinuxlich> I wish Crystal had a Pulsar client
gangstacat has joined #crystal-lang
<FromGitter>
<phykos> how do I have to bootstrap the compiler?
<FromGitter>
<Blacksmoke16> in what regard? building from source or?
<FromGitter>
<Blacksmoke16> or without crystal already installed?
<FromGitter>
<phykos> building from source
<FromGitter>
<Blacksmoke16> is crystal already installed? If so should just have to run `make`
<FromGitter>
<phykos> yes I have the 0.35.0 compiler
<FromGitter>
<Blacksmoke16> how much memory you got?
<FromGitter>
<phykos> 4G
<FromGitter>
<Blacksmoke16> hm, might not be enough
<FromGitter>
<phykos> how
<FromGitter>
<Blacksmoke16> how what?
<FromGitter>
<phykos> I mean I have never used so much ram on my Pi
<FromGitter>
<Blacksmoke16> compiling the compiler takes a quite a bit of memory
<FromGitter>
<Blacksmoke16> prob better of cross compiling
<FromGitter>
<Blacksmoke16> off*
<FromGitter>
<phykos> Now I have 4 threads and each one of those is using +/-50% of my ram
<FromGitter>
<phykos> I dont have a pc other than my rpi
<FromGitter>
<Blacksmoke16> :/ might be out of luck then
<FromGitter>
<phykos> Maybe I can try to pass to `make` `-j 2`?
<FromGitter>
<Blacksmoke16> could try adding a few gigs of swap
<FromGitter>
<phykos> Uhh right
<FromGitter>
<phykos> s/rigth/right
<mps>
iirc, crystal builds with single thread by default
<mps>
builds self*
<FromGitter>
<phykos> I have 4 threads by just running `make`
<FromGitter>
<Blacksmoke16> doesnt really matter, main constraint is just not enough memory
<FromGitter>
<phykos> K then
<mps>
hmm, I usually looks when building it for alpine and never seen more than one thread
<FromGitter>
<phykos> Tomorrow I'll try with a 16G swap file on my HDD
<mps>
more threads only seen in initial phase which is before actually crystal build starts
<FromGitter>
<phykos> On it I have used 160G/1TB so I could doing like anything
<mps>
hm, 'crystal build --verbose --target aarch64-alpine-linux-musl --release --progress --threads 8 --link-flags=...' but 'ps' shows only one thread and we have '--threads 8'
<FromGitter>
<watzon> When I'm finished with the marionette improvements it should work properly with any webdriver, not just geckodriver like the current version uses
<FromGitter>
<j8r> @dscottboggs_gitlab Yes, I didn't maintain because there are now official Alpine images
<yxhuvud>
release mode without thin-lto flag enabled always end up doing the bulk (optimization) of the work in single thread. and I am not certain if it can be enabled for building self (where do you put the flag to enable thin-lto, for starters?)
<yxhuvud>
(I'm also not aware if actually enabling thin-lto do enable use of more cpus, but at least the restriction is in another place then)
<jhass>
well, maybe 1.0-dev already matches as 1.0
<jhass>
so is not < 1.0
<jhass>
error could be improved at least then
<oprypin>
jhass, ok but i never specified < 1.0
<jhass>
it's assumed if you specify nothing iirc
<oprypin>
ok why? lol
<jhass>
to force the ecosystem to specify it
<oprypin>
thats dumb
<FromGitter>
<wontruefree> Is there a way to create an unmanaged object in Crystal. I have been looking and hacking around a bit and could not find a way
<jhass>
make it easier to find usable stuff post 1.0, I guess
<FromGitter>
<wontruefree> I was going to open an RFC but I wanted to check here first
<jhass>
call LibC.malloc?
<jhass>
or LibGC.malloc_uncollectable
<FromGitter>
<wontruefree> I didn't see LibGC.malloc_uncollectable in the api
<jhass>
maybe it's not there, I don't remember
<jhass>
but it exists
<jhass>
in bdwgc
<jhass>
GC_malloc_uncollectable
<FromGitter>
<wontruefree> malloc uses GC_malloc
<jhass>
Pointer#malloc does, LibC.malloc not
<FromGitter>
<wontruefree> I was trying to use LibC.malloc
<FromGitter>
<wontruefree> seems like it works but I was just curious if there was another way
<jhass>
I guess technically LibC.malloc is a luck game anyway, because bdwgc does not know it and may overwrite it
<FromGitter>
<wontruefree> it might overwrite it ?
<FromGitter>
<wontruefree> how
<jhass>
it allocates itself using sbrk, not malloc
<FromGitter>
<wontruefree> no way
<jhass>
yeah
<jhass>
causes all kinds of funny issues
<FromGitter>
<wontruefree> I didnt know that would cause a problem
<FromGitter>
<wontruefree> I thought malloc would request a different mempage from the OS how does sbrk conflict with that?
<jhass>
in C it does #define malloc with a tracer wrapper
<jhass>
I don't know, I just know it does
<jhass>
through stuff crashing
<FromGitter>
<wontruefree> I just read the man page I think I could see how it would be a problem. I dont know enough about OS.