<FromGitter>
<jwoertink> ok, if I add `namespaces: {"xhtml" => "http://www.w3.org/1999/xhtml"}` to the xpath call, and prefix every single element with `xhtml` then it works
<FromGitter>
<jwoertink> I feel like this is still a bug though.
<FromGitter>
<girng> `Simply by requiring "parallel", replacing spawn with pspawn, and Channel with PChan, this simple example will execute in only 3 seconds.`
<FromGitter>
<girng> ima try this myself, looks epic :D
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
greengriminal has joined #crystal-lang
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
greengriminal has quit [Quit: This computer has gone to sleep]
greengriminal has joined #crystal-lang
<hightower2>
Well, figured the issue with all 'crystal' commands just hanging... I realized /opt/crystal/bin/crystal is a shell wrapper. And a pretty bad one at that. It tries to manipulate PATH, but fails to remove /usr/local/bin/ from path, so /usr/local/bin/crystal keeps re-invoking itself in a busy loop
<FromGitter>
<girng> never had that issue are u on WSL? @hightower2
<hightower2>
the logic how the wrapper works and tries to call the actual binary is just bad
faustinoaq has quit [Quit: IRC client terminated!]
faustinoaq has joined #crystal-lang
greengriminal has quit [Quit: Leaving]
Raimondi has quit [Ping timeout: 240 seconds]
<FromGitter>
<fridgerator> @girng shouldnt it be `pspawn { handle_master_connection(socket) }` ?
<FromGitter>
<fridgerator> or `pspawn do`
<FromGitter>
<girng> spawn handle_master_connection(socket) works though, but i will try with the brackets 1 sec
<FromGitter>
<fridgerator> you made an issue that it doesnt work?
<FromGitter>
<fridgerator> oh i see
<FromGitter>
<girng> yah
<FromGitter>
<fridgerator> does it work with brackets?
<FromGitter>
<girng> just tried brackets, same thing hmm
<FromGitter>
<fridgerator> you get wrong number of arguments for `pspawn` even without arguments ?
<FromGitter>
<girng> tested that, yp
<FromGitter>
<girng> yep
<oprypin>
girng, you can look into having multiple processes listening to the same port (reuseport) but not through this library
<FromGitter>
<fridgerator> adding the brackets worked for me
<FromGitter>
<fridgerator> fyi
<FromGitter>
<girng> wat
<FromGitter>
<girng> how
Raimondi has joined #crystal-lang
<FromGitter>
<fridgerator> it didnt throw an exception the program just sat there, i'm assuming that means it didnt work
<FromGitter>
<fridgerator> worked*
<FromGitter>
<girng> fail. i was modifying a diff file
<FromGitter>
<girng> the {}'s do work.
<FromGitter>
<girng> @fridgerator thank you, i guess i'l close my issue then ty
<FromGitter>
<girng> @op
<FromGitter>
<girng> @oprypin are u saying we can't use parallelism for tcp connections through it? i mean, i did just try the brackets to get rid of that error, and it does work
<FromGitter>
<girng> is there a linux cmd to check what cores being used by a PID
<FromGitter>
<girng> i can monitor it to see
<Majost>
Is the newer logger initializer not available in 0.24.2?
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<Majost>
Ah... just checked the tag, and its not in 0.24.2
snsei has quit [Remote host closed the connection]
<Majost>
Bummer
<FromGitter>
<bew> ah right, then no, we need the 0.25 release, which will hopefully come soon
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei has quit [Remote host closed the connection]
<Majost>
Is there a good debugging primer for newbs? I just got my first runtime error which I am not sure how to step through and debug: Invalid memory access (signal 11) at address
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 276 seconds]
rohitpaulk has joined #crystal-lang
<FromGitter>
<bararchy> C bindings ?
<FromGitter>
<bararchy> Majost are you doing C bindings?
<oprypin>
Majost, ever heard of printf debugging? don't need to know anything for it
<oprypin>
of course you'd use `pp` instead
<FromGitter>
<girng> haha
<oprypin>
anyway, this is my go-to method
<txdv>
whats the alternative to a interface in crystal?
<FromGitter>
<epergo> because you are accessing `in_game_object` which is an instance variable that can be Nil (Game?) so the compiler doesn't know if when accessing players that game is really a game or nil, doesn't matter if you checked before
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter>
<manveru> hi folks, just starting out with Crystal, do you know if there's a way to get a proc from a singleton method? So if i have `class X; def self.y; end; end`, in ruby i'd `X.singleton_method(:y)`
<FromGitter>
<yxhuvud> oh, sort of like a guard lite.
<FromGitter>
<manveru> i assume it's somehow failing setting up stdout/stderr?
<FromGitter>
<manveru> it's pretty weird, as `crystal build` also fails...
<FromGitter>
<yxhuvud> Yeah, the current version is doing some strange things there. I think it is fixed on head but I don't have time to look in the issues to find the relevant one
<FromGitter>
<yxhuvud> well it would fail for everything compile with the crystal compiler, which includes the compiler itself
<FromGitter>
<bararchy> Fiber cannot be killed from outside
<FromGitter>
<bararchy> unless main Fiber exits
<FromGitter>
<girng> i have an idea
<FromGitter>
<petoem> you should be able to use a channel to signal the fiber to close
<FromGitter>
<girng> can i set a boolean (for example, property close_game =false). then, inside my tickrate do ` if close_game return end`, will return blank, and close the loop/fiber
<FromGitter>
<girng> i can call close_game externally
<hmans>
So, re Crystal threads, I'm assuming that if I magically take care that any variable I work with is thread-local (including any code I use from the stdlib), I should be fine?
<FromGitter>
<bararchy> I think sleep calls schedular then Fiber boom
<RX14>
sleeping is the same as IO
<RX14>
exactly
<FromGitter>
<bararchy> yeha what RX14 said
<RX14>
IO and sleep both call the scheduler
<RX14>
because they are nonblocking
<RX14>
LibC.sleep you wont get a segfault
<FromGitter>
<bararchy> Oh
<FromGitter>
<bararchy> god idea :)
<FromGitter>
<bararchy> good
<hmans>
Oh, cool
<FromGitter>
<bararchy> but t.join is better
<FromGitter>
<bararchy> because it will block until thread returns
<RX14>
you can use threads if your code is purely numerical and manually allocated
<FromGitter>
<bararchy> RX14 I really wanted to use threads in SHAInet but I couldn't figure out where I can use them in the sense that they wont crash
<RX14>
i've always wondered why you're writing your own neural stuff
<RX14>
instead of using an existing C library
<RX14>
which is doubtless far better optimized
<FromGitter>
<bararchy> you will be suprised
<FromGitter>
<bararchy> we started with FANN, which don't have nothing new, then you can use TensorFlow which lacks neural network api for C (only in python), so we checked CudNN but it's hell to bind and makes no sense, so Torch, but there are no docs and it's a total black box
<FromGitter>
<bararchy> We also needed something supre customized for our needs
<FromGitter>
<bararchy> what we do is really out of the norm regarding Machine learning
<FromGitter>
<bararchy> RX14 ⏎ ⏎ Neural Network library: A number of components that together support the creation of neural network models and training them (possibly in a distributed setting). While it would be convenient to have this available in other languages, there are currently no plans to support this in languages other than Python. These libraries are typically wrappers over the features described above.
<FromGitter>
<drujensen> I think its an interesting experiment in that you can have different types of neurons instead of tensor based approah. It has real ground breaking potential.
<FromGitter>
<bararchy> thanks @drujensen :) we thought soo to, we like this macro approch instead of type by layer
<FromGitter>
<drujensen> All of the current solutions do the same thing
<FromGitter>
<drujensen> this can change the way back propogation works
<FromGitter>
<drujensen> the biggest concern with an OO approach would be to leverage a gpu but that is another hurdle for another day. ;-)
<FromGitter>
<bararchy> true
<FromGitter>
<bararchy> because Matrix multiplication is hard
<FromGitter>
<bararchy> in OO approch
<FromGitter>
<bararchy> we can just throw Neuron class at the GPU
<FromGitter>
<drujensen> I love that you are modeling the Neurons to different types memory, eraser, amplifier, sensor. I ccan’t wait to see how this will work.
<Vexatos>
matrix multiplication in Julia: C = A * B
* Vexatos
runs
<Vexatos>
I'd love a good crystal library for matrix mathematics
<duper>
Are there any DNS libraries for Crystal? Does't seem that the standard library supports DNS at all.. :/
<FromGitter>
<yxhuvud> vexatos: there are some bindings to blas in a few different libraries.
<FromGitter>
<yxhuvud> they are not very mature though
<RX14>
duper, what do you eman doesn't support dns?
<Vexatos>
@bararchy I mean I get you won't be able to make it as neat as the way Julia does it, but that is almost on the level of Java matrix libraries
<RX14>
Vexatos, you can override * operator
<RX14>
so yes
<Vexatos>
It also seems fairly old
<RX14>
you can make it that neat
<duper>
RX14.. like I don't see any functions documented if I wanted to create a request for an arbitrary record.. like CHAOS TXT, for example..
<RX14>
yeah no we don't have that
<Vexatos>
RX14, like, A = [1 2 3; 4 5 6; 7 8 9]?
<RX14>
that requires a proper DNS resolver
<RX14>
Vexatos, thats not what you said
<RX14>
and you can get close with macros
<hmans>
Anyone here ever work with ponylang/ponyc?
snsei has quit [Remote host closed the connection]
jokke1 has quit [Ping timeout: 240 seconds]
jokke1 has joined #crystal-lang
<duper>
RX14: *nod* that's why I'm asking if there's a C interface for one..
<RX14>
not off the top of my head
<duper>
if not, can I make one myself? ..or can you just not do DNS in crystal?
<RX14>
well you can bind a C library yourself
<duper>
Can crystal do raw sockets? I construct the datagram manually if I have to..
<RX14>
sure it can
<duper>
hmm..
<RX14>
isn't DNS udp?
<duper>
yes
<RX14>
don't need raw sockets then
<RX14>
just use UDP sockets
<RX14>
if you really want to implement a pure-crystal DNS resolver
<RX14>
which would be cool and useful
<RX14>
because it'll be properly evented instead of binding a C resolver which won't integrate well with crystal's even tloop
<duper>
It was originally _only_ DNS when the first RFC's came out..and only DNS-update was TCP (how nameservers authoritative for same zone(s) communicate with each other) but nowadays it can be either TCP or DNS
<RX14>
i presume you mean UDP not DNS for half of that
<duper>
no.. I mean TCP
<duper>
the latest RFC specifies that it's both protocols
<RX14>
yes
<duper>
but the original RFC was UDP only
<RX14>
you said "it can be either TCP or DNS"
<duper>
DNS-Update is the protocol for zone transfers
<RX14>
which doesn't make sense
<RX14>
"TCP or UDP" is surely what you meant to say
<RX14>
from basic googling I can't find any DNS shards so you'd have to write your own
<RX14>
starting with UDP will get your the most use for your effort though
<duper>
oops.. meant TLS.. which is the latest RFC
<RX14>
is it TLS-only on TCP?
<RX14>
interesting
<duper>
okay, so if Crystal can interface to C without any changes
<duper>
it's HTTPS
<duper>
you can do TLS over UDP though
<RX14>
yeah I know
<RX14>
actually i'm confused now
<RX14>
because hasn't DNS supported TCP forever when the query was large
<RX14>
and the recent support was for HTTPS or TLS
<RX14>
well whatever
<duper>
is it possible to make calls to C libraries without specifying data marshalling if the library is compiled with debugging symbols
<duper>
RX14, when the response was large, yes.. that's why i said zone transfers.. but there was also ZXFR (compressed zone transfers) if you _really_ still wanted to do it over UDP
<RX14>
duper, no
<RX14>
you have to recreate the headers in crystal
<FromGitter>
<bararchy> DNSSEC
<RX14>
ok yeah I get it now: it was always UDP/TCP and the recent RFC was for DNS over TLS
<duper>
RX14, okay, but if I modified the crystal language itself.. is there any reason it would not be possible?
<FromGitter>
<bararchy> Oo modify the language itself ?
<duper>
RX14, no.. it was not always TCP
<RX14>
there would be reasons why it wouldn't be practical
<RX14>
namely it would be hard to implement
<FromGitter>
<bararchy> duper I never seen DNS query go over anything other then UDP53
<RX14>
it would be of limited use since most distros strip debug symbols
<RX14>
the better idea would be to make the compiler parse headers with libclang
<RX14>
honestly it's not much effort to hand-write library bindings
<FromGitter>
<bew> there are tools that does exactly that and generates the Crystal' header for a C lib
<RX14>
(and none of them are very good for this usecase)
<duper>
RX14, this is a library I wrote myself.
<duper>
so keeping the symbols is not a problem
<FromGitter>
<bew> (true too)
<RX14>
duper, why not just write the library yourself
<RX14>
i mean write the bindings*
<duper>
and it symbols are stripped there is also RTTI with C++
<RX14>
we don't bind C++
<RX14>
since it's mangling is unspecified
<duper>
RX14, I can.. it would just be more convenient if I didn't have to, especially when there's lots of functions exported
<duper>
the mangling is specified.. it just varies by compiler
<RX14>
so it's unspecified
<RX14>
and in addition does your library have facility to integrate with an event loop
<RX14>
because otherwise you're going to be blocking on IO a lot
<duper>
I understand that this isn't something that has to be done.. my question is _can_ it be done?
<RX14>
if you can get the neccesary info from the debug info which I don't know then sure
alex`` has joined #crystal-lang
<duper>
i am also surprised that this does not exist already.. i figured someone would have wrote these for a dns library already since it's such a common thing to be programming with
<RX14>
it's not really
<RX14>
most people just need gataddrinfo
<RX14>
which we alreadu have
<duper>
meh.. can't even specify the nameserver with that
<duper>
and it's not re-entrant.. inet_pton is the new one
<RX14>
inet_pton doesn't do dns?
<duper>
true, but it converts the representation of the address like get*info
<duper>
is the interface for getaddrinfo already written at least?
<RX14>
"unlike the latter functions, getaddrinfo() is reentrant"
<RX14>
duper, yeah
<RX14>
otherwise we wouldn't be able to do basic networking
<RX14>
without a way to convert a host to an IP
<duper>
hmm.. okay, i stand corrected.. i think it was the get*by* family then
<duper>
if it has things like this for the socket library? what about the standard c library?
<RX14>
what do you mean?
<RX14>
that is in the standard library
<RX14>
and it uses standard libc getaddrinfo
<duper>
hmm.. isn't that bsd sockets?
<duper>
i mean glibc might put it in glibc.so, but i don't think it's actually standard c
<RX14>
yes it's in the sockets part of the stdlib
<duper>
its posix
<duper>
okay, so anything in libc i can call without writing an interface by default?
<RX14>
no
<RX14>
parts of it
<duper>
ah
<duper>
ok next question..
<RX14>
and the parts of libc which are bound are unspecified
<RX14>
and subject to change
<RX14>
I don't see why you'd want to
<RX14>
when you can just use the wrapper we provided
<duper>
i was reading a blog and i think it said that 80% or so if crystal is written in crystal.. how does it remain so fast? i've written a bit of scheme (racket and guile) and the parts that were written in scheme always slowed it down
<duper>
s/so if/so of/
<RX14>
80%?
<RX14>
crystal is 99% written in crystal
<duper>
don't remember the exact number can get you the link
<RX14>
there's about 5 lines of C
<RX14>
and thats it
<RX14>
and that part could be eliminated
<RX14>
obviously we depend on shard libraries written in C
<RX14>
and crystal is so fast because it's entirely compiled
<RX14>
the only thing keeping crystal slower than C is that we're a GC'd language
<duper>
so is Go
<RX14>
yeah
<RX14>
and we're about as fast as go
<duper>
i thought it was faster
<RX14>
depending on workload we're going to trade blows
<RX14>
for IO we currently beat go
<duper>
i just bought a book about go and now i wish i didn't
<RX14>
for GC/allocation bound workflows go will beat us
<duper>
that language requires too much typing and learning when i can get the speed from a ruby-like syntax already
<RX14>
because go has escape analysis and a better GC
<duper>
oic
<duper>
how come crystal doesn't allow single quote string literals like ruby? i couldn't even do a require 'uri'
<duper>
i always felt like they were faster since there's no interpolation
<RX14>
because single quotes is char
<RX14>
and crystal is compiled, why would there be a difference?
<duper>
hmm
<RX14>
the compiler knows whats interpolated and whats not statically
<duper>
is a single byte char or are there wchar_t's as well?
<duper>
like rune's in Go
<RX14>
it's a unicode codepoint
<RX14>
so 32bit
<duper>
what if I want a single byte char?
<RX14>
strings are in utf-8
<RX14>
what for?
<RX14>
we have a UInt8 if you want a byte
<duper>
a lot of C functions use them
<duper>
ah
<RX14>
so you don't want a char youw ant a byte
<RX14>
C has bad naming :P
<duper>
true
<RX14>
we have signed and unsinged types for every power of two from 8 bits to 128
<RX14>
and 32/64bit floats
<RX14>
if you're binding C and want the platform definition of a "C Char" you can use LibC::Char
<duper>
is there a ruby->crystal transpiler yet?
<RX14>
which is an alias for whatever int type it is on that platform
<RX14>
duper, no because it wouldn't be possible
<RX14>
because ruby is dynamically typed and crystal is statically typed
<duper>
oh, duh.
<RX14>
you could write a ruby interpreter
<RX14>
but that wouldnt be a good idea
<duper>
so what can Go do that Ruby can't? (i really don't care about the lack of windows/arm support either)
<RX14>
crystal and go have armsupport
<RX14>
and do you mean go or crystal?
<duper>
err. crystal
<duper>
i read somewhere that it didn't have arm support
<RX14>
nope
<duper>
but i don't care
<FromGitter>
<bararchy> RX14 but the rasberiPi works no?
<RX14>
yes
<RX14>
thats why I said crystal has arm support...
<FromGitter>
<bararchy> Oh
<FromGitter>
<bararchy> I thought you meant the opposite
<FromGitter>
<bararchy> duper Crystal do have ARM support
<FromGitter>
<bararchy> Or you meant Go doesn't have?
<FromGitter>
<bararchy> Hard to follow this conversation lol
<RX14>
makes sense to me
<RX14>
duper, well the benefits of crystal over ruby is slightly cleaned up syntax and stdlib
<RX14>
speed
<RX14>
type safety
<RX14>
proper CSP concurrency
<FromGitter>
<faustinoaq> Hey @/all crystal community, I just finished to port amber docs to GitBook, please Take a look! https://amberframework.org/ 🎉 ✨ 😄