jhass changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.7.6 | Fund Crystals development: http://is.gd/X7PRtI | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/ | Logs: http://irclog.whitequark.org/crystal-lang
trapped has quit [Read error: Connection reset by peer]
<Kilo`byte> okay in the end that was some pretty good information i got here today :P
<Kilo`byte> kinda too tired to dig into that some more now though, will do tomorrow
no0p has joined #crystal-lang
ssvb has quit [Ping timeout: 256 seconds]
<Kilo`byte> anyways, time to sleep
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 244 seconds]
ssvb has joined #crystal-lang
kyrylo has quit [Ping timeout: 255 seconds]
ssvb has quit [Ping timeout: 246 seconds]
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 246 seconds]
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 250 seconds]
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 265 seconds]
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 250 seconds]
havenwood has joined #crystal-lang
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 264 seconds]
zamith has joined #crystal-lang
zamith has quit [Ping timeout: 260 seconds]
BlaXpirit has joined #crystal-lang
blue_deref has quit [Quit: bbn]
havenwood has quit [Quit: Textual IRC Client: www.textualapp.com]
zamith has joined #crystal-lang
Ven has joined #crystal-lang
zamith has quit [Ping timeout: 260 seconds]
leafybasil has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
leafybasil has quit [Ping timeout: 244 seconds]
zamith has joined #crystal-lang
zamith has quit [Client Quit]
ssvb has joined #crystal-lang
kyrylo has joined #crystal-lang
zamith has joined #crystal-lang
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
salvor has quit [Changing host]
salvor has joined #crystal-lang
kyrylo has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
kyrylo has joined #crystal-lang
kyrylo has quit [Remote host closed the connection]
kyrylo has joined #crystal-lang
tatey_ has joined #crystal-lang
kulelu88 has joined #crystal-lang
<RX14> is it convention to require "a_library" or "a-library"
<BlaXpirit> dashes are not recommended
<BlaXpirit> RX14,
<RX14> oh, why?
Ven has joined #crystal-lang
<RX14> i have installed 2 libraries using crystal deps but I can only require one of them
<RX14> this is strange
<BlaXpirit> RX14, meh, write "tree" in your project folder and paste that somewhere
<RX14> wait what the fuck?
<RX14> a github repo anme with a _ in breaks it
<RX14> it's called crystal_irc
<RX14> and it generates as libs/irc
<RX14> oh derp
<RX14> it removes the crystal but doesn't it
<RX14> that also breaks the library
<BlaXpirit> RX14, pls stop accusing random things. this is expected and documented behavior
<RX14> LOL my IRC library is 10x faster than thor's
<RX14> BlaXpirit, i know but it looks like thor didn't take account of that behaviour
<BlaXpirit> not unlikely
trapped has joined #crystal-lang
<thor77> uhm, what?
<RX14> 5.8 million irc messages per second on a shit celeron
<RX14> celeron M
<thor77> jhass told me to use _ instead of -
<RX14> thor77, if you name your github repo crystal_irc yor library must be called irc
<RX14> because crystal deps strips the crystal_
<RX14> and links it to libs/irc
<thor77> weird
<thor77> is your irc-lib available on github?
<RX14> yup
<RX14> github.com/RX14/fast-irc
<RX14> github.com/RX14/fast-irc.cr
<RX14> will rename it to fast_irc soon
<RX14> i am kinda cheating seeming as I only parse the IRC params when they are requested
<RX14> it's deferring work as late as possible
kyrylo has quit [Remote host closed the connection]
<RX14> if I parse the params too then i'm only 3x faster
<RX14> hmmn, I might want to late-parse the prefix too
<RX14> then it's just basically string.split lol
<thor77> if i find some time to extend my irc-libary, i will integrate your parser, too
<RX14> i still need to do ircv3 and some more optimisations
<thor77> (ofc you can also submit a pull request if you want to speed up the process of integration ;))
<RX14> hmmn, I might want to make my own library and framework
<RX14> i don't know much about this new evented io stuff, or how to get the socet bytes into my faster as fast as possible
<RX14> socket*
<RX14> parser*
zamith_ has joined #crystal-lang
qb has quit [Ping timeout: 246 seconds]
rvchangue has quit [Ping timeout: 246 seconds]
zamith has quit [Ping timeout: 244 seconds]
guilleiguaran__ has quit [Ping timeout: 246 seconds]
zz_Cidan has quit [Ping timeout: 246 seconds]
rvchangue has joined #crystal-lang
AckZ has quit [Ping timeout: 246 seconds]
willl has quit [Read error: Connection reset by peer]
aemadrid has quit [Read error: Connection reset by peer]
willl has joined #crystal-lang
qb has joined #crystal-lang
aemadrid has joined #crystal-lang
guilleiguaran__ has joined #crystal-lang
AckZ has joined #crystal-lang
<BlaXpirit> >> s = "abc"; s.cstr[0] = 100u8 # wondering what causes this
<DeBot> BlaXpirit: Failed to run your code, sorry! - http://carc.in/#/r/cmt
<asterite> RX14: you could try to rewrite your parser using CharReader: http://crystal-lang.org/api/CharReader.html , because indexing a string is pretty slow (because... UTF-8)
gamemanj has joined #crystal-lang
<RX14> asterite, i'm not sure if it's faster
zz_Cidan has joined #crystal-lang
<asterite> and the benchmark that new implementation and the old one and see if it makes a difference
<RX14> i will
<BlaXpirit> how can I allocate a string of some size and pass it to a C function to fill?
<BlaXpirit> I know i can pass it pointer to array of uint8 then convert
<RX14> just Slice.new
<asterite> You can try, if you feel like doing so. I always like super fast performance :-P . You should try with non-hardcoded strings, because if you write "foo" then the compiler knows that that is ascii and will optimize index accesses
<asterite> BlaXpirit: http://crystal-lang.org/api/String.html#new%28capacity%2C%20%26block%29-class-method
<RX14> Slice(UInt8).new(size) BlaXpirit
<BlaXpirit> oooh right, asterite. thanks
<asterite> Ah, no, not that one
<asterite> Oh, yes, that one
<RX14> or that
<RX14> that works
<BlaXpirit> i've bumped into that one multiple times, should've remembered
<RX14> that's better
<RX14> i forgot about that
<RX14> what's strange is that sometimes links inside docs pages work and sometimes they don't
<RX14> on firefox that link just goes to the top of the page
<BlaXpirit> yup
<BlaXpirit> time for someone to fix that, huh
<BlaXpirit> i really should look into it
<asterite> Yes, it works on chrome... I should have tested on firefox
<asterite> web development is still harder than writing a compiler :(
<RX14> true
<RX14> i really want to port a few ruby templating languages to crystal
<BlaXpirit> make sure it's something that looks like ECR
<RX14> why?
<RX14> I want something nice
<RX14> we already have ecr
<BlaXpirit> i like that syntax, and it's the same syntax as the most popular templating engine in python
<BlaXpirit> well similar at least
<RX14> well if i was going to port a templaying lanmgauge it would be one I like
<BlaXpirit> :p
<RX14> slim-lang.com
<RX14> this one
<RX14> this actually compiles templates into ruby, but I bet I could write a crystal emitter for the temple template compilation framework
<RX14> so that the template is parsed in ruby, but it emits crystal
<RX14> so that's basically the hacky 0-work solution
<RX14> any temple templating langauge could probably work
Ven has quit [Read error: No route to host]
<BlaXpirit> RX14, uhh ECR does that
<RX14> what do you mean?
<jhass> RX14: slim has a non-evaling version that could be interesting to have a native crystal parser for
<RX14> jhass, yes it does
<RX14> but i want slim in crystal ASAP so i will do the hacky solution first
<jhass> BlaXpirit: guess it's pointing somewhere inside the data section of the binary, not the heap
<jhass> yap, Bad permissions for mapped region at address 0x11AE44
<RX14> asterite, i'm going to start testing the CharReader version, but I think the original will be faster
<RX14> because the original is just working with a Slice(UInt8), and not realing with ascii at all
<RX14> s/ascii/utf-8/
BlaXpirit has quit [Remote host closed the connection]
BlaXpirit has joined #crystal-lang
<Netfeed> port jinja2 instead :)
<BlaXpirit> Netfeed, that's what im saying
<RX14> you can if you want
<RX14> but I won't
gamemanj has quit [Ping timeout: 260 seconds]
<Netfeed> just skip making a template language at all and just return a script-tag that does everything in a SPA-page :P
<RX14> ach, it's too much work to port to CharReader
<RX14> and i'm sure it will be slower
ssvb has quit [Ping timeout: 252 seconds]
<BlaXpirit> RX14, i did use your slice suggestion for a 0terminated string of unknown length
<BlaXpirit> buffer = Slice(UInt8).new(16); CSFML.ip_address_to_string(self, buffer); String.new(buffer.to_unsafe)
<BlaXpirit> thx
<RX14> i reccomend asterite's suggestion though
<BlaXpirit> RX14, it's unapplicable here. i would need to apply strlen manually. String.new does it for me
<RX14> hmmn
<RX14> i don't know that function so whatever
<BlaXpirit> i was getting like "0.0.0.0\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}"
<RX14> ah, i see
<RX14> that makes sense
kulelu88 has left #crystal-lang ["Leaving"]
<RX14> you could have done it with a pointer and malloc but Slice is probably nicer
<RX14> now i'm getting about 20 million IRC parses per second
<RX14> 17 million if I parse the params
<RX14> woah
<RX14> i wonder if it's just optimising away my everything
kyrylo has joined #crystal-lang
<Netfeed> i'm starting to think that i'm blind, where is File#print defined? I can see that it's used in File.write, but i can't really find the actual method
<vegai> Netfeed: might it be IO
<Netfeed> aah
<BlaXpirit> vegai, but it doesnt inherit from io
<BlaXpirit> ah includes bufferediomixin
<Netfeed> ok, so File includes FileDescriptorIO, which includes BufferedIOMixin, which includes IO
<Netfeed> sigh
<BlaXpirit> Netfeed, :(
<vegai> ah, ok
<BlaXpirit> File subclassses*
<Netfeed> so, print uses to_s before it writes, is it possible to write a bytestream directly?
<BlaXpirit> Netfeed, huh? what do you actually want to do?
<BlaXpirit> shouldn't just writing a string do it?
<Netfeed> well, i'm considering what happens if you want to copy a large file for example
<Netfeed> there's always #write_byte i guess
<Netfeed> or just #write
<BlaXpirit> so how can we fix the anchor names in crystal docs?
<BlaXpirit> very few characters are actually allowed
<BlaXpirit> letters, numbers and -_:.
<BlaXpirit> instead of #each(&block)-instance-method it could be #each-instance-method-md5hash
<BlaXpirit> why won't c.between('a', 'z') work
<BlaXpirit> should Char include Comparable(self) ?
tatey_ has quit []
<BlaXpirit> welp, looks like simply removing spaces fixes it for firefox
<BlaXpirit> nevermind
Rishav has joined #crystal-lang
havenwood has joined #crystal-lang
Rishav has quit [Ping timeout: 246 seconds]
ssvb has joined #crystal-lang
Codefriar has joined #crystal-lang
asterite has quit [Ping timeout: 246 seconds]
asterite has joined #crystal-lang
rossjones has quit [Ping timeout: 246 seconds]
rossjones has joined #crystal-lang
Ven has joined #crystal-lang
Ven has quit [Remote host closed the connection]
<Kilo`byte> BlaXpirit: huh? whats wrong with the links?
<Kilo`byte> actually, which links :P
Ven has joined #crystal-lang
kostya has joined #crystal-lang
shama has joined #crystal-lang
dylanmei has quit [Quit: ZZZzzz…]
Ven has quit [Ping timeout: 246 seconds]
NeverDie has joined #crystal-lang
ytti has joined #crystal-lang
ytti has quit [Ping timeout: 248 seconds]
NeverDie has quit [Max SendQ exceeded]
NeverDie has joined #crystal-lang
<Kilo`byte> wait, whats libpcl?
<RX14> okay so I have my IRC parser, what would be the fastest and best way to get network IO into it?
<RX14> i'm not experienced with low-level IO...
NeverDie has quit [Max SendQ exceeded]
<Kilo`byte> RX14: i use socket.gets
<Kilo`byte> reads the next line from a socket
<jhass> Kilo`byte: where the current coroutine implementation comes from
<Kilo`byte> ic
<Kilo`byte> why do you implement the context switch yourself though
<jhass> dunno, I heard it's faster or more flexible or something
<jhass> in any case a dep less is a win already
<RX14> hmmn
<Kilo`byte> i am looking into playing with that stuff in c++ and i am thinking about implementing something myself
<Kilo`byte> but not sure :P
<RX14> I might modify my library to read directly from an IO...
<jhass> RX14: not necessarily faster given evented io
<Kilo`byte> yup
<jhass> if you gets and process in a new coroutine the main one can already read the next line while you process
<RX14> so you gets and pass it off to a coroutine
<RX14> where are coroutines doculemted?
<jhass> that's what I'd try first
<Kilo`byte> and to spawn a coroutine use spawn do ... end
<RX14> any more docs on them?
<jhass> given the docs for spawn are empty...
<RX14> shoot
<Kilo`byte> thats really all you need to know. they effectively work like a thread
<jhass> and the ones for Channel too...
<RX14> well, how do I order the IRC messages then
<Kilo`byte> jhass: actually, can a coroutine access sourrounding variables or do you need channels
<jhass> uh, I think it closures
<Kilo`byte> well, its a block after all
<jhass> but I don't actually know
<Kilo`byte> so i'd expect it to, but you never know
<Kilo`byte> it might break things horribly
<RX14> how do I keep the irc messages in order?
<jhass> by not using concurrency at all or only a single coroutine and a channel
<jhass> that is like in threading, Channel replacing Queue, a reader, a writer a processor or so
<Kilo`byte> hmm this might be a valid concern: signal handlers might run on and coroutines stack
<jhass> well yeah, I think signal handler IO is broken too
<Kilo`byte> well, i am thinking about signals to shut down stuff
<Kilo`byte> it might be the best to launch the signal handler in its own coroutine
ytti has joined #crystal-lang
ytti has quit [Ping timeout: 248 seconds]
<Kilo`byte> trap :INT do spawn do ... end end
<jhass> coroutines are cheap though, spawning one for each message is feasible
<Kilo`byte> jhass: yup
<Kilo`byte> you don't even need threadpools :D
<Kilo`byte> i am really happy i learned about them, will probably use them in all my stuff now xD
<Kilo`byte> well, low-level stuff
<Kilo`byte> probably libpcl for now though
<jhass> so you can just block them on a channel and a different one sends a message to that channel if it sees a event you're waiting for
NeverDie has joined #crystal-lang
<Kilo`byte> jhass: just curious, does the crystal api expose manual coroutine stuff
<Kilo`byte> like manually resuming a certain coroutine
<jhass> well, all crystal is crystal so you can always break through the abstractions
<Kilo`byte> true
<jhass> Fiber itself is an abstraction
<Kilo`byte> thing is: if i don't watch out i might break existing things
<jhass> yeah
<Kilo`byte> whoawhoahwoah
<Kilo`byte> that might be interesting
<Kilo`byte> usermode fork
<Kilo`byte> should be doable
<Kilo`byte> you just have to clone the stack pretty much
<Kilo`byte> (sadly afaik there is no api to do CoW cloning)
<Kilo`byte> yeah, i am excited about this stuff ;)
Ven has joined #crystal-lang
<RX14> hmmn, how to ensure there's only one coroutine
<jhass> never use spawn
<RX14> no I meant one parsing coroutine for irc
<RX14> do I want to spawn a new coroutine every time , or to queue the slices for the parsing coroutine to do
<jhass> both can be valid approaches, kind of depends on the application
<jhass> I tend to spawn a new one after reading a line from the socket and do the parsing as well as calling any handlers in it
<jhass> *I would
<jhass> calling the handlers concurrently can get messy pretty fast anyway
<RX14> then how do you make sure you have only one coroutine running so that the events are sent in order
<Kilo`byte> well, unlike threads, coroutines will never just stop at some point
<Kilo`byte> the coroutine has to explicitely say: run a different coroutine please
<jhass> as said I wouldn't rely on order, I'd block the handler's coroutine until I see an event I'm waiting for
<jhass> after installing a handler that will wake me up
<jhass> channel = Channel.new; connection.on(FOO) do |message| channel.send(message); end; foo = channel.receive; foo_happened
<jhass> + uninstalling the handler and stuff
<jhass> since the handler will run in a new coroutine spawned after the message was received that'll work
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<RX14> well i'm really confused now
<jhass> if you want the receiving be driven by the library user just skip all that
<jhass> have def receive; parse(@socket.gets); end; and be done
<jhass> er, if you don't want
<jhass> no, it was right, I need to eat something
<jhass> will shut up and do that now
<RX14> well i'm not really sure how channels work
<RX14> and there are no docs
<Kilo`byte> RX14: a channel is basicly a tube where you stuff in something one end and it comes back out the other end
<Kilo`byte> both ends can be in sepreate coroutines
<jhass> it's just like Queue
<jhass> except for coroutines
<Kilo`byte> RX14: small demo of channels: http://carc.in/#/r/coi
<jhass> asterite: btw any ETA for Channel.select?
<jhass> oh, wait, it's already there? how did I miss?
<Kilo`byte> Scheduler.reschedule <- i assume that tells it to call a different coroutine
<Kilo`byte> right?
<jhass> yeah
<jhass> that's what I gathered too at least :P
<Kilo`byte> so crystal doesn't do a tree based coroutine model
<Kilo`byte> which is what libpcl uses
<Kilo`byte> and might be why it implements the context switch itself
<jhass> it doesn't yet
<jhass> that was a branch
<Kilo`byte> ook
<Kilo`byte> because thats what libpcl does by default
<RX14> so handle_fork on httpserver runs 8 crystal processes?
<jhass> but anyway, I expect all that to change quite a bit with the workstealing scheduler
<jhass> RX14: that API will likely be removed
<RX14> why?
<jhass> because it doesn't fit into the evented IO approach
<Netfeed> forking webservers is quite efficient, so why would that be removed?
<Kilo`byte> yeah
<Kilo`byte> well, i would keep forking in itself
<jhass> read those two
<RX14> well, #listen is only single core
<Kilo`byte> hmmm
<Kilo`byte> i think you should address that somehow
<RX14> how would we use all my 8
<RX14> my dedi has 8 quite shit cores
<RX14> but all 8 together is really quite fast
<Kilo`byte> like, that coroutines can run on multiple different threads
zamith__ has joined #crystal-lang
<Kilo`byte> kinda like an OS takes multiple threads and runs them on different cpus you could take multiple coroutines and run it on different threads
<Kilo`byte> s/cpus/cpu cores
<Netfeed> isn't this a problem with the forking not spawningn a completly new runtime for each child?
zamith_ has quit [Ping timeout: 246 seconds]
zamith__ has quit [Ping timeout: 255 seconds]
<Kilo`byte> there is actually a thing i have thought about for quite some time: a centralized way to produce sockets (read: socket factory)
<Kilo`byte> so, lets say you have a HTTP connection. you can on creation pass it a socket factory to generate the socket. said factory could for example wrap the socket in a TLS stream or pipe it over a proxy
<Kilo`byte> so you don't have to care about TLS support or proxy support in every protocol you need
<Kilo`byte> or the irc library by person X could use the TLS implementation of person Y
<RX14> well, i'm going to leave my IRC impl for now, I hope one of you takes my implementation and gives it some error checking and some sort of framework
qard has joined #crystal-lang
<RX14> i like the cinch irc, hopefully that will eventaulyl exist for crystal
<RX14> basically, nick my parsing code and stick it in your own library.
<Kilo`byte> i am going to make an irc lib, not sure if i'll use your code though as i already have my own parser
<Kilo`byte> well, i am not completely sure if i will
<Kilo`byte> but i probably do
<RX14> well I hope you take the idea that iterating over the slice of bytes makes it faster
<Netfeed> RX14: cinch is great
<RX14> and that less parsing is better
<RX14> also never go backwards
<Netfeed> i might need to update my plugins to support >1.9.3 if the don't
<RX14> always go forwards on your slice: one pass and that's it
<Kilo`byte> RX14: i have a very basic parser that a good half a million parses done per second
<Kilo`byte> should be sufficiently fast
<RX14> yeah but sufficiently fast is not fun at all :P
<Kilo`byte> if you give me your code i can benchmark it against mine tho
<RX14> it's on github
<Kilo`byte> well, i need a link, github is large
<RX14> it was 3x faster than thor77's code and on the last bench his was faster than yours
<RX14> github.com/RX14/fast-irc.cr
<Kilo`byte> so if you were to add tag support it'd probably actually be viable
<RX14> yeah
<Kilo`byte> i ain't gonna write an irc lib without tag support :P
<RX14> you could write tag support...
<Kilo`byte> yeah
<Netfeed> tag?
<Kilo`byte> well, later, not in mood now :P
<Kilo`byte> Netfeed: ircv3 tags
<Kilo`byte> @account=Kilobyte22 :Kilo`byte!~kilobyte@cucumber.kilobyte22.de PRIVMSG #crystal-lang :test
<Kilo`byte> thats an example message
<RX14> maybe I might have a crack at ircv3 before dropping it
<Kilo`byte> there also is a time tag (used by for example bouncers so the client can display the time the message actually arrived at the bouncer)
<Kilo`byte> and various others
<Kilo`byte> RX14: would be cool :P
<RX14> Kilo`byte, what's your code to generate an IRC message from parsed?
<RX14> there's one failing test on travis to do with that
<Netfeed> i read the spec for tags, but i don't really get the point
<Kilo`byte> Netfeed: adding metadata to messages that is useful to the client
<Netfeed> alright
<Kilo`byte> like the nickserv account of the sender (useful for bots)
<Kilo`byte> and i am fairly sure they will be used more in the future
<Netfeed> oh ok
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14> ircv3 escaping is a pain in the ass
<Netfeed> i'm happy frameworks like cinch just abstract that stuff away so i don't have to think about it
<Kilo`byte> i am fairly sure cinch doesn't support them
<Kilo`byte> most ircds don't either
<Kilo`byte> but afaik the one freenode uses actually does support them
<Kilo`byte> let me try that
<Netfeed> i think dominik stoped active developement of cinch so i guess it's not in it
<Kilo`byte> right, i am connected through a bouncer
<Kilo`byte> off to telnet i go
<RX14> heh
<RX14> it's mostly useful for client/bouncer communication
<Kilo`byte> :adams.freenode.net 421 kilotest @test :Unknown command
<Kilo`byte> nope, might be wrong
<Kilo`byte> or its only server -> client
<Kilo`byte> :adams.freenode.net CAP kilotest LS :account-notify extended-join identify-msg multi-prefix sasl
<Kilo`byte> no tag involving capabilities
dylanmei has joined #crystal-lang
<Kilo`byte> so it seems to not support them. must've misread
<Kilo`byte> RX14: seriously though, with your implementation it might actually be possible to write an irc server in crystal
<Kilo`byte> its certainly fast enough
Raimondi has quit [Quit: The road to wisdom?—Well, it's plain and simple to express: Err and err and err again, but less and less and less. — Piet Hein]
<RX14> ... why not
<RX14> they are written in C
<RX14> why not crystal?
<Kilo`byte> or c++
<Kilo`byte> yup
<Kilo`byte> and its certainly easier to maintain
Raimondi has joined #crystal-lang
<Kilo`byte> only downside: no runtime plugin loading
<RX14> it's just being efficient
<Kilo`byte> but with scripting you can get around that
* Kilo`byte looks at mruby
<RX14> i saw a game written in C++ that could reload itself using LLVM magic
<RX14> they just pressed a button and all classes reloaded themselves and the gamed carried on
<RX14> it was pretty magic
<Kilo`byte> well, the thing is: garbage collector and the fact that a methods param types depend on how the method is called make this hard
<RX14> yeah, it would be really cool if this was possible though
<Kilo`byte> it might work if all the api methods would have fixed param types
<Kilo`byte> but it sounds really hacky to me
<RX14> anyway time to parse ircv3
<Kilo`byte> what should be doable though is the abilty to restart without dropping connections
<Kilo`byte> fork ftw
dylanmei has quit [Ping timeout: 245 seconds]
<Kilo`byte> if anything, the server would lag for a second
<Kilo`byte> at most
<RX14> yeah yeah, let me get this actually done first
<Kilo`byte> heh :P
<Kilo`byte> good luck :P
<RX14> i got a benchmark of 20M messages per second once
<RX14> but I can't remember how
<Kilo`byte> quite intested in how fast your tag parsing will be compared to mine
<Kilo`byte> mine is like: split all the things
<RX14> i have really fallen in love with vim
<Kilo`byte> good boy :P
<Kilo`byte> i use atom for crystal dev though
<Kilo`byte> >> ({} of String => String|Nil)["test"]
<DeBot> Kilo`byte: KeyError: Missing hash value: "test" - more at http://carc.in/#/r/cok
<Kilo`byte> goood :P
<RX14> crystal vim is okay
<Kilo`byte> for bigger stuff i prefer a regular text editor
<Kilo`byte> command line editing or small hacky stuff? vim.
<RX14> well I just use gvim for everything
<RX14> unless theres an IDE
<RX14> then I use the IDE
<RX14> unless youcompleteme has a plugin for that langauge
Ven has joined #crystal-lang
<RX14> and I use ideavim for IDEA too
<Kilo`byte> well, i could see rubymine getting crystal support at some point :P
<RX14> me too
<RX14> if jetbrains did a crystal IDE
<RX14> my lord
<Kilo`byte> well, ruby and crystal are so similar, it should not be THAT hard to integrate it into rubymine
<Netfeed> the vim plugin is taking up alot of process for me
<RX14> Netfeed, it's laggy for me too
<Kilo`byte> it won't happen before crystal gets to 1.0 though
<RX14> i thought it was just this shit celeron m laptop
<Netfeed> the editing is fine, the moving around in files is not
<RX14> yup
<RX14> same
<RX14> i'll open an issue
<Kilo`byte> let me try
<Kilo`byte> Netfeed: actually, what cpu do you run?
<Kilo`byte> > cpu
<Kilo`byte> > run
<Kilo`byte> what am i smoking
<Netfeed> an intel i7 @ 3.4ghx
<Netfeed> ghz
<RX14> well if it's laggy on that...
<Kilo`byte> okay, idk what you are complaining about. i opened my parser in vim (with crystal plugin) and scrolled through it like 20 times
<Kilo`byte> no issue at all
<RX14> if I hold j it lags
<Kilo`byte> not a bit
<Netfeed> strange
<RX14> yeah...
<Kilo`byte> and i am on an i5 @ 3.10GHz
<RX14> Kilo`byte, are your colours on?
<Kilo`byte> yes
<RX14> Netfeed, do you have syntastic installed?
<Netfeed> no
<RX14> hmmn
<RX14> NERDTree?
<Kilo`byte> you using vim or gvim?
<RX14> gvim
<Kilo`byte> i am using vim in this case
<Netfeed> nope, and i'm using vim
<RX14> or maybe it's powerline
<Netfeed> moving around in a file, albeit with a string in it that's 10-15 rows and it takes 15% cpu, up from 2%
<Kilo`byte> are we talking about the same plugin
<Kilo`byte> using vim-crystal-git from the AUR
<RX14> i'm using vim-crystal installed with vundle
<RX14> yes that one
<Kilo`byte> RX14: as -git might suggest i am using the git version
<Kilo`byte> idk how vundle works
<RX14> vundle gets the latest I think
<RX14> just checks it out
<Kilo`byte> so that'd be same
<Kilo`byte> what version of vim
<Netfeed> 7.4
<Kilo`byte> 7.4.778
<Kilo`byte> (full version please)
<RX14> huh
elbow_jason has joined #crystal-lang
<RX14> i updated the plugin and it seems to work?
<Kilo`byte> well, looks like it was just recently patched then
<Kilo`byte> as i just installed it myself
<Netfeed> Kilo`byte: http://pastebin.com/THnHWYVH
<RX14> well, the changelog doesn't look like it
<RX14> this is the only non-docs commit
<Kilo`byte> Netfeed: so you use 7.4.52
<Kilo`byte> "Included patches: 1-52"
<RX14> I use 778
<Raimondi> macvim?
<Kilo`byte> Raimondi: arch, official repos
NeverDie has joined #crystal-lang
<Raimondi> that's pretty old in terms of the new regex engine, maybe that why it's so slow for you
<Raimondi> try using the old engine with :set re=1
<Kilo`byte> also why does debian not fucking use the packages the way they are
<Kilo`byte> why do they have to patch everything?!
<RX14> i hate debian for that
<RX14> i don't want a 1 year old patched to fuck package
<RX14> I want the fucking upstream
<RX14> and I want it quick
<RX14> grr is makes me mad
<Kilo`byte> RX14: nope, even with using that it doesn't break
<Kilo`byte> err Raimondi ^
<Raimondi> Kilo`byte: if you are using 7.4.778 that wouldn't break anything, that might help if you are using 7.5.52
<Kilo`byte> ook
<Raimondi> help, as in run faster
<Raimondi> 7.4.52 *
<Kilo`byte> oh i thought you meant the old one being worse
<Kilo`byte> xD
<Kilo`byte> so i should use the old one to see if i can reproduce it
<Raimondi> Kilo`byte: nope, since 7.4.52 a lot of patches were meant to fix the new regex engine, so with 7.4.778 you won't be able to reproduce it.
<Kilo`byte> i wonder what the best way for an inter-server irc linking protocol would be. use an existing one (ie. inspircd) roll own irc based one or fully custom
<Kilo`byte> fully custom would probably bring best performance
<Raimondi> YOU'd need to install 7.4.52 or something close to that
<Kilo`byte> nah
<Kilo`byte> i am not happy with that old packages :P
<Raimondi> ruby syntax is known to be hard on vim, so if vim-crystal's syntax is based on that I won't be surprised it runs slower than the rest
dylanmei has joined #crystal-lang
<Netfeed> ok, i updated to http://askubuntu.com/questions/641668/how-can-i-update-vim-in-ubuntu-14-04lts and i now have 7.4.683 and i still get an extra 14-15% cpu for some files
<Raimondi> even worst with long lines
<Kilo`byte> Raimondi: hows the parsing going?
<Kilo`byte> err
<Kilo`byte> RX14: ^
<Kilo`byte> i hate having 2 people talking whose names start with same char
<Kilo`byte> murphy ensures the person you want to talk to is never the one who sent the last message
<Raimondi> /nick xRaimondi
<Kilo`byte> we also need efficient data outputting
<RX14> Kilo`byte, yeah, appending to IO shouldn't be too bad right?
<RX14> i might bench it
<Kilo`byte> well
<RX14> an ircd in crystal...
<Kilo`byte> idk if IO is buffered
<RX14> Kilo`byte, it's just IO
<RX14> it can be or it can't be
<RX14> depends on what IO you use
<Kilo`byte> hmm
<RX14> i just implemented to_s(IO)
<RX14> then aliased to_irc to it
<Kilo`byte> that should work
<Kilo`byte> what you might wanna do is a using a StringIO (does that exist?) to implement parameterless to_s and to_irc
<Kilo`byte> not that a sane person would use those for high performance
<RX14> i think I will leave the parsing and emitting on it's own and make it just a parser library
<BlaXpirit> huh
<RX14> Kilo`byte, crystal does that man
<BlaXpirit> Kilo`byte, String.build is as good as StringIO
<RX14> look at to_s on object
<BlaXpirit> and that's what to_s(io) does
<Kilo`byte> it does?
<RX14> yes
<Kilo`byte> thats good to know
<RX14> ...
<BlaXpirit> thats the whole point of to_s(io)
<RX14> read the docs :P
Ven has quit [Remote host closed the connection]
<RX14> i didn't modify your unit tests BTW
<Kilo`byte> heh :P
<RX14> although your tests didn't seem to test prefix parsing
Ven has joined #crystal-lang
<Kilo`byte> huh?
<Kilo`byte> RX14: ^
<RX14> no i meant parsing inside a prefix
<Kilo`byte> i don't do any of that
<RX14> you don't test that the user nick and host are extracted
<RX14> and yes I saw
<Kilo`byte> thats not part of the irc parser imo
<RX14> it is
<RX14> you need to extract the nick out of it when you reply to a privmsg
<RX14> the prefix is something that you need to parse all the time
<Kilo`byte> yeah, that would be done in the User class though imo
<Kilo`byte> or w/e class is used for that
<RX14> and seeming as I was iterating over that part of the message to get to the command anyways, I thought it was be nice to parse
<Kilo`byte> well, depending on the application you have completely different things here
<Kilo`byte> could be a server name, a nickname, a nickmask or UID
<RX14> Kilo`byte, i have tested the preformance difference between parsing it and not parsing the prefix and it was something like 1.2x
<RX14> it's totally worth it
<Kilo`byte> (myserver.example.net, kilobyze, kilobyte!kilo@kilobyte22.de, 311AAOA8G)
<Kilo`byte> nickname and uid are usually only used on servers though
<Kilo`byte> like, inter-server links
<Kilo`byte> RX14: maybe add a seperate parser for that which you just delegate the nick parsing to
<Kilo`byte> and you can swap out that parser depending on your needs
<RX14> no
<Kilo`byte> no, like you'd give it the io after seeing the :
<Kilo`byte> and when it returns you know it has consumed the prefix
<RX14> i tried to remove functions from the whole thing
<RX14> if I did that I would split the code into a macro and macro it into the parse method and a seperate method
<RX14> functions would require passing both the slice and the position in and out
<Kilo`byte> well, if you can handle all of those 4 scenarios, i'd be fine if you added it :P
<Kilo`byte> oh okay i thought you were reading from the io
<RX14> will i parse the prefix according to the spec
<Kilo`byte> not using a slice
<RX14> Kilo`byte, no I have slice and position
<RX14> I think it might be faster
<Kilo`byte> well you gotta iterate over it twice
<RX14> seeming as it's just messing with pointers
<Kilo`byte> once to find the end of line
<Kilo`byte> one to parse it
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RX14> Kilo`byte, yeah, i was thinking of making it take IO
<RX14> but then it becomes a buffering issue
<RX14> if I could get me a slice of that IO buffer
<Kilo`byte> afaik crystal has decent IO buffering
<RX14> just a straight slice
<RX14> wait you can do .@ can't you
<RX14> muhaha
<Kilo`byte> you can do that if you like being slapped by fellow developers, yeah
<RX14> i don't mind
havenwood has quit [Quit: Textual IRC Client: www.textualapp.com]
<Kilo`byte> i'd make it generic though, so said parser returns a T
<Kilo`byte> and your parser also returns a T for the prefix
kostya has quit [Remote host closed the connection]
<Kilo`byte> said T can be for example a string(server <-> server links) or a tuple (server <-> client)
<RX14> all the buffered IO copies from the buffer
<RX14> i want raw access
<Kilo`byte> RX14: keep in mind, the buffer might not contain the full message
<RX14> yeah
<Kilo`byte> in fact, it might not have been sent yet
<RX14> yup
<RX14> it's more trouble than it's worth
<Kilo`byte> RX14: that has to happen anyways though
<RX14> well i think gets is basically the fastest way
<Kilo`byte> whether its in the parser or before the parsing is done
<Kilo`byte> well, i am just saying
<RX14> whatever we actually do, it will be fast enough
<Kilo`byte> yeah
<RX14> what was I doing again
<RX14> ircv3 parsing!
<Kilo`byte> yay
<RX14> your to_irc must be horribly slow
<Kilo`byte> now for emitting
<RX14> well ym emitting kinda works
<Kilo`byte> RX14: i never actually benchmarked it
<RX14> will you work on my implementation with me?
<Kilo`byte> sure
<RX14> if you try and optimise the emitting and get it right, i will work on ircv3 parsing
<Kilo`byte> sure
<Kilo`byte> did you commit your latest changes?
<RX14> let me...
<RX14> Kilo`byte, yes
<Kilo`byte> >> !!0
<DeBot> Kilo`byte: # => true - http://carc.in/#/r/cop
<Kilo`byte> >> if 0; "test"; end
<DeBot> Kilo`byte: # => "test" - http://carc.in/#/r/coq
<Kilo`byte> RX14: watch out for that ^
<Kilo`byte> wait
<Kilo`byte> i can't read
<RX14> >> !0
<DeBot> RX14: # => false - http://carc.in/#/r/cor
<RX14> >> 0.to_bool
<DeBot> RX14: Error in line 4: undefined method 'to_bool' for Int32 - http://carc.in/#/r/cos
<RX14> >> 0.to_b
<DeBot> RX14: Error in line 4: undefined method 'to_b' for Int32 (did you mean 'to_i'?) - http://carc.in/#/r/cot
<RX14> whatever
<RX14> i don't do if x
<RX14> well
<RX14> ix number
<RX14> if*
<BlaXpirit> RX14, "!= 0" is ".to_b"
<Kilo`byte> de
<Kilo`byte> does crystal have memcopy?
<BlaXpirit> Kilo`byte, probably, it depends on what u need
<Kilo`byte> copy x bytes at one buffer to another one
<RX14> Slice.copy_to
<RX14> is the safe way
<BlaXpirit> yeah, that's a good general answer
<RX14> hmmn
<RX14> we can get C's memcry right?
<Kilo`byte> so to copy a string into a slice at a certain location i need to create 2 slices?
<RX14> Kilo`byte, but slices are basically free
<Kilo`byte> hmm
<BlaXpirit> Kilo`byte, no, just one, and ^
<RX14> it's no memoryt copying
<RX14> they are structs
<RX14> and it's pointer + int
<Kilo`byte> hmmm tbh, i got busy, will look into that in an hour or so
<BlaXpirit> actually, Kilo`byte, i didn't use slices in my code
<BlaXpirit> this is memcpy
<RX14> are those pointers?
<BlaXpirit> @buffer is the only pointer involved
<RX14> yes
<RX14> so they are pointers
<BlaXpirit> to.copy_from(from, n)
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<RX14> github is having a fit
<BlaXpirit> unicorn?
<RX14> a unicorn appeared
<BlaXpirit> seen that one today
<RX14> and the file finder tool like 20s to load
<RX14> pointer.copy_from uses memcpt
<RX14> memcpy*
<Kilo`byte> i thought that was my local connection
<Kilo`byte> because that really shitty recently
<RX14> and the slice.copy_from uses the pointer copy_from
<RX14> directly
<RX14> so it's all memcpy
<RX14> look at status.github.com
<BlaXpirit> seems correct
<RX14> it's just spiked
<Kilo`byte> and memcpy compiles to a single instruction iirc
<RX14> been graduly rising
<RX14> Kilo`byte, but it's got all that wrapper crystal code...
<RX14> i hope that gets optimised out
<Kilo`byte> RX14: ever heard of inlining? :P
<RX14> > "I hope that gets optimised out"
<RX14> meaning inlined
<Kilo`byte> also mind adding a http:// before links?
<RX14> no
<RX14> because i typed them
<RX14> and my irc client works witht hem
<RX14> why copy and paste when you can type faster?
<Kilo`byte> my terminal doesn't :P
<RX14> get a better terminal
<Kilo`byte> since that'd be greatly unhelpful in a terminal
<RX14> yeah my one doesn't too
<RX14> never mind
<RX14> damnit Kilo`byte you keep getting me distracted from the ircv3 parser!
<Kilo`byte> xD
<RX14> I would have thought that macros basically pasted their results into where they were called but aparrently they have some kind of special context by themselves
<Kilo`byte> RX14: you can actually run of subset of crystal in them at compile time
<RX14> i know
<RX14> but if you copy a block of code X out of a function and put it in macro Y and call macro Y where X was, you don't always get the same result
<jhass> Kilo`byte: it's not a subset, it's a different language really
<Kilo`byte> is it?
<jhass> do you have for? ;)
<RX14> yes
<jhass> outside of macros
<RX14> oh
<RX14> ohh
<RX14> is it parsed in a totally different codepath?
<jhass> the stuff in {% %} is
<RX14> anyways i'm mot talking about macro code
<RX14> i'm talking about the result
<jhass> the result is fed back into the regular parser
<jhass> yes, I was replying to Kilo`byte
<jhass> can't do much about you applying my reply to a different context :P
<RX14> i had to add a var :: XXX to counteract a variable not found error
<jhass> macros have their own local variable scope, yes
<RX14> that is strange
<RX14> it should really be a copy and paste kind of mechanic
<jhass> I guess the idea is prevent conflicts, make the macro opague for the caller
<jhass> but given we have %macro_vars now that should indeed maybe be reconsidered
<jhass> mmh
<RX14> yes please
<RX14> pwease
<jhass> thinking about it the actual reason might be that when the result is parsed the parser doesn't have access to the target context
<jhass> so it's actually sort of an implementation side effect
<RX14> whatever it is it's a pain
<jhass> not sure I agree, having to properly setup the context of a macro sounds like insane coupling
<jhass> I think what you actually want is an @[AlwaysInline] flag for methods
<RX14> that would be very nice
<RX14> but it doesn't really solve this
<jhass> point being that you shouldn't write macros where it matters
<RX14> i basically want a slice of code copied and pasted from 2 different contexts
<RX14> and macros should be able to do that
<jhass> repeating your initial statement won't change the counter argument ;)
<Kilo`byte> rust does hygenic macros
<Kilo`byte> if you want a macro to define a variable accessible outside of it, you have to pass the name as a parameter
<Kilo`byte> i like that concept
<RX14> crystal macros can't properly access the ast can they?
<Kilo`byte> i think they can. to a degree at least
<RX14> they can't modify stuff arbitrarily
<RX14> like modifying the contents of a method?
<BlaXpirit> RX14, probably can
<jhass> the callable methods need to be mapped out by hand: https://github.com/manastech/crystal/blob/master/src/compiler/crystal/macros/methods.cr
<jhass> mmh, I wonder
<jhass> >> macro foo(var); puts {{var}}; end; bar = "hi"; foo(bar)
<DeBot> jhass: hi - more at http://carc.in/#/r/cou
<jhass> there, we have hygenic macros too
<jhass> >> macro foo(var); puts {{var.upcase}}; end; bar = "hi"; foo(bar)
<DeBot> jhass: in line 4: undefined macro method 'Var#upcase' - http://carc.in/#/r/cov
<BlaXpirit> >> macro foo(var); puts {{var}}; end; bar = "hi"; foo("asdf")
<DeBot> BlaXpirit: asdf - more at http://carc.in/#/r/cow
<RX14> well of course you can do that, but the point is to enforce that
<RX14> Kilo`byte, I still havent started the ircv3 parsr
<RX14> i'm so bad at this
<RX14> what's a pain is that this private macros calling other private macros hasn't been fixed
<RX14> i have to basically duplicate macros
<RX14> unless I want macros in the global namesspace
<RX14> i had to make a module containing all of my macros just to keep them off the global namespace
<RX14> hmmn
<RX14> Kilo`byte, should prefix#to_irc include the : or now?
<RX14> not*
<RX14> I would say no
<Kilo`byte> nah
<RX14> Kilo`byte, pushed
<RX14> added that Prefix.parse method you wanted
zamith__ has joined #crystal-lang
<Kilo`byte> RX14: is the parser done?
<RX14> not for v3
<RX14> hell no I havent even started
<Kilo`byte> kk
<Kilo`byte> RX14: if params = params
<Kilo`byte> what is that line supposed to do?
<BlaXpirit> Kilo`byte, this actual line seems to make no sense
<BlaXpirit> unless it means if params = self.params
<RX14> yeah that's what it meant
<RX14> params = params()
<BlaXpirit> then it means params = self.params; if !params.is_nil yadda yadda
<RX14> where was that again
<Kilo`byte> params = params will define a variable and self-assign it
<Kilo`byte> at least thats what it does in ruby
<RX14> it works
<RX14> i know it works
<BlaXpirit> ok ok
<RX14> fine i made it self.params
<Kilo`byte> params.try might work as well
<BlaXpirit> this is cooler
<RX14> pushed it to github
<RX14> and params.try might be less efficient
<RX14> Kilo`byte, can you write some specs for the prefix class?
qard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Kilo`byte> uh sure
havenwood has joined #crystal-lang
qard has joined #crystal-lang
<jhass> RX14: you need to have more trust in LLVM inlining things :P
<RX14> i don't have any trust in what I can't inspect
<RX14> or unit test
<Kilo`byte> RX14: how am i supposed to access the values?
<RX14> Kilo`byte, what do you mean?
<RX14> prefix has getters
<Kilo`byte> oh wrong file
<RX14> yes
<RX14> i split the implementation into 2 files
<RX14> it's a bit strange
zamith__ has quit [Ping timeout: 244 seconds]
rob_ has joined #crystal-lang
Ven has joined #crystal-lang
<RX14> ugh optomising this tag parsing will be a apin
<RX14> a pain*
willl has quit [Quit: Connection closed for inactivity]
<RX14> i'm going to say that constructing a map is expensive
Ven has quit [Ping timeout: 264 seconds]
qard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
qard has joined #crystal-lang
<Kilo`byte> RX14: Error in ./src/fast-irc/message.cr:45: undefined local variable or method 'to_irc'
<Kilo`byte> u dun goofd
<asterite> RX14: there's no need to trust LLVM, just do --release --emit llvm-ir (or llvm-bc, asm, or obj) and check the generated code ;0
<asterite> ;)
<jhass> :D
<jhass> mmh, managed that HTTP::Client blocks forever :/
<Kilo`byte> E...FF....F....F
<Kilo`byte> RX14: there are your test results
<Kilo`byte> going to PR now
<Kilo`byte> actually split a test and it changed to E...F.FF....F....F
<RX14> Kilo`byte, can you fix them?
<Kilo`byte> i can give you test result
<Kilo`byte> sec
<RX14> and the tests please
<RX14> oops
<RX14> fixed the lack of : before prefix
<RX14> also Kilo`byte how do you detect hosts?
<Kilo`byte> . in the name
<RX14> oh for flips sake
<RX14> that's a pain
<Kilo`byte> we can do that differently though if its a lot of inconvenience
<Kilo`byte> like a flag thats lazily evalualted
<RX14> it's not too much
<RX14> Kilo`byte, can you fix the beugs with the to_irc emitter
<Kilo`byte> jhass: do if, while etc do automatic to_b
<RX14> let me give you push to github
<Kilo`byte> sure
<jhass> no
<Kilo`byte> hmm
<Kilo`byte> so i can't just implement lazy {} for booleans
<Kilo`byte> although thats probably a tough one anyways, as it does require use of method_missing
<jhass> we do have macro method_missing ;P
<RX14> isn't it macro def?
<Kilo`byte> ya
<RX14> Kilo`byte, you have access
<Kilo`byte> but thing is: i can't do if my_lazy_var and have that evaluate to false if the boxed value is false
<Kilo`byte> RX14: can you address the other emitting issues
<Kilo`byte> err
<Kilo`byte> parsing
<Kilo`byte> sorry
<RX14> yeah
<RX14> can you amke an issue for the parsing issues, my memory is shit
<RX14> wait
<RX14> no
<RX14> they are in the specs
<RX14> never mind
<Kilo`byte> yup
<RX14> also can you push those new specs?
<Kilo`byte> i did
<Kilo`byte> well, to my repo
<Kilo`byte> right
<Kilo`byte> thought i had done a pull request
blue_deref has joined #crystal-lang
<Kilo`byte> RX14: fixed the one emit bug that was there
<RX14> maybe I should make a library for late-binding data structures
<RX14> Kilo`byte, have you pulled?
<RX14> I fixed the : bug
<Kilo`byte> yes
<Kilo`byte> otherwise i wouldn't have been able to push :P
<Kilo`byte> because git is smart and won't let you push if your local repo is not up to date
<Kilo`byte> <3 git
<RX14> Kilo`byte, you can's do "if user = @user"
<RX14> wait
<RX14> can I
<RX14> yes you can sorry
<Kilo`byte> yup
<Kilo`byte> and its more performant using the variable directly
<Kilo`byte> instead of the getter
<RX14> I forgot that i changed it from late-creating string
<RX14> user used to be a slice_getter
<RX14> and I forgot
<Kilo`byte> wait wait wait
<Kilo`byte> idea
<Kilo`byte> i looked into this for ruby and couldn't find an easy way
<Kilo`byte> crystal this should be easy
<Kilo`byte> "getter stuff?" should compile to "def stuff?; @stuff; end"
<RX14> Kilo`byte, also you do if user = @user but never use the user
<Kilo`byte> uh thats stupid
<Kilo`byte> yeah
<Kilo`byte> "property stuff?" should compile to "def stuff?; @stuff; end; def stuff=(value); @stuff = value; end"
<Kilo`byte> RX14: shall i fix or will you?
<RX14> you
<Kilo`byte> there
<RX14> i'm wondering about how actually to late-create the ircv3 tags
<Kilo`byte> late-create?
<RX14> because I don't want to be allocating strings while parsing
<Kilo`byte> you could make a list of tuples of slices
<Kilo`byte> and then convert them later
<Kilo`byte> like
<RX14> well
<RX14> nah
<Kilo`byte> Array({Slice(UInt8), Slice(UInt8)?})
<Kilo`byte> seriously, i don't see why not to allocate strings during parsing
<RX14> it's expensive
<Kilo`byte> probably more performance
<Kilo`byte> well
<RX14> copying from my slice
<Kilo`byte> you have to do it anyways
<Kilo`byte> either during parsing or afterwards
<RX14> yeah but a real user never uses all the fields
havenwood has quit [Ping timeout: 240 seconds]
<Kilo`byte> lazy evaluation :P
<RX14> yes
<RX14> that
<Kilo`byte> make the tags getter parse the tags
<Kilo`byte> if they are never used they are never parsed
<RX14> i suppose that's the only way
<Kilo`byte> thats the most efficient way at least
<RX14> it does mean I have to iterate that part twice though
<Kilo`byte> meh
<Kilo`byte> on average more performance than not doing it
<RX14> yeah I suppose
<Kilo`byte> like probably many times
<Kilo`byte> because tags aren't really used much atm
<RX14> yup
<RX14> i wonder if they are usually used if they are sent though
<RX14> because if they are not sent it's just an if statement
<RX14> it just skips that whole part entirely
<Kilo`byte> they are usually used if sent
<Kilo`byte> as you have to explicitely enable the capabilities
<RX14> yeah
<RX14> hmmn, hmmn
<RX14> i think I will late-evaluate them anyways
<RX14> lazy evaluate*
<RX14> $ crystal spec
<RX14> Program terminated abnormally with error code: 139
<RX14> oh dear
<Kilo`byte> thats...
<RX14> 139 is segfault right?
<RX14> it didn't print anything...
<Kilo`byte> >> 139 - 127
<DeBot> Kilo`byte: # => 12 - http://carc.in/#/r/cp6
<Kilo`byte> >> Signal.SEGV
<DeBot> Kilo`byte: Syntax error in eval:4: expecting any of these tokens: IDENT, +, -, *, /, %, |, &, ^, **, <<, <, <=, ==, !=, =~, >>, >, >=, <=>, ||, &&, ===, [], []=, []?, ! (not 'CONST') - http://carc.in/#/r/cp7
<Kilo`byte> >> Signal::SEGV
<DeBot> Kilo`byte: # => SEGV - http://carc.in/#/r/cp8
<Kilo`byte> >> Signal::SEGV.value
<DeBot> Kilo`byte: # => 11 - http://carc.in/#/r/cp9
<Kilo`byte> hmm
<RX14> so what is 139?
<Kilo`byte> 12 would be USR2
<RX14> wat
<Kilo`byte> so prob a calulting error
<Kilo`byte> and it is in fact signal 11
<Kilo`byte> like error on my part
<RX14> so a segfault?
<Kilo`byte> ya
<Kilo`byte> i wonder where it locates the binary
<Kilo`byte> >> tempfile "test"
<DeBot> Kilo`byte: Error in line 4: undefined method 'tempfile' - http://carc.in/#/r/cpa
<Kilo`byte> >> Crystal.tempfile "test"
<DeBot> Kilo`byte: Error in line 4: undefined constant Crystal - http://carc.in/#/r/cpb
<RX14> crystal-rub-spec.tmp
<Kilo`byte> dang
<RX14> run*
<Kilo`byte> thanks
<RX14> in the .crystal folder
<Kilo`byte> RX14: well, then run gdb on that
<Kilo`byte> :P
<RX14> i have never used gdb
<RX14> i have no idea how to debug
<RX14> and I don't want to learn
<Kilo`byte> why not? :P
<Kilo`byte> gdb isn't too hard to use
<RX14> i dunno
<RX14> i'll try it out
<Kilo`byte> once the file is loaded use the run command
<Kilo`byte> it'll automatically break on segfault
<Kilo`byte> then you can get a backtrace using the bt command
<RX14> okay
<Kilo`byte> sadly crystal doesn't include debug symbols on llvm 3.6
<Kilo`byte> so no line numbers
<RX14> interesting
<RX14> also
<Kilo`byte> but you get (mangled) method names
<RX14> did it include line numbers?
<RX14> and why does it no longer
<Kilo`byte> because on llvm 3.5 it did that
<Kilo`byte> llvm changed the apis for that
<Kilo`byte> or something
<Kilo`byte> crystal does work with llvm 3.5 though ;)
<Kilo`byte> just replace 3.6 with 3.5 and recompile crystal
<RX14> more work
<RX14> is llvm 3.5 on the aur?
<Kilo`byte> yes
<Kilo`byte> llvm35
<Kilo`byte> but the crystal aur package won't work with it
<RX14> Kilo`byte, why?
<Kilo`byte> its a dependency on llvm
<Kilo`byte> and llvm35 doesn't provide llvm
<Kilo`byte> jhass: can you help with that stack trace?
<RX14> that's strange
<RX14> it's in String#inspect
<Kilo`byte> looks like a thing in standard lib
<RX14> I can provide the binary too
<RX14> BTW i'm on 32-bit
<Kilo`byte> hmm
<jhass> prolly invalid memory access? valgrind provides better error messages on those
<Kilo`byte> well, i am on 64 bit and it works fine
<Kilo`byte> haven't used valgrind yet
<RX14> .g valgrind
<RX14> what si valgring
<jhass> package-manager-install valgrind
<jhass> valgrind ./binary
<jhass> you'll see
<Kilo`byte> pacman \o/
<Kilo`byte> (worlds best package manager)
* RX14 uses `inst valgrind`
<Kilo`byte> p -S valgrind for me
<Kilo`byte> p being an alias for pacaur --color=always
<RX14> i use yaourt
<jhass> Access not within mapped region at address 0x16
<Kilo`byte> RX14: is that the code thats in the repo?
<jhass> you overrun the pointer
<travis-ci> decioferreira/crystal#be7c803 (master - Better document `eval` command. Related to #1263): The build passed. https://travis-ci.org/decioferreira/crystal/builds/77056354
<RX14> I didn't
<jhass> Kilo`byte is just lucky to have some mapped memory there
<RX14> that's in the stdlib
<Kilo`byte> ic
<jhass> uh, asterite ^?
<Kilo`byte> well thing is
<Kilo`byte> for me there is no indication in any unit test that such a thing happened
<RX14> i don't use any unsafe types
<asterite> jhass: tell me
<RX14> so this shouldn't be happening
<jhass> asterite: check that gist
<RX14> it's in string#inspect
<asterite> how can I reproduce it?
<Kilo`byte> i can post my valgrind too
<RX14> Kilo`byte, but you don't segfault
<RX14> so it's kinda
<RX14> asterite, i have no idea
<Kilo`byte> i still get those uninitialized memory ones
<Kilo`byte> and it might be useful, so why not
<RX14> i can reproduce it on my laptop :P
<asterite> RX14: but you have some code that triggers that, right?
<RX14> not on x64 aparrently
<jhass> any of you here is github.com/decioferreira ?
<Kilo`byte> not me
<Kilo`byte> i wonder
<Kilo`byte> does the context switch code actually work on x86? because it uses 64 bit registers
<Kilo`byte> at least thats what i remember
<Kilo`byte> (the new one that is)
DeBot has quit [Quit: Crystal IRC]
<RX14> i stashed my changes and I was on the latest revision (same as Kilo`byte) and i still segfaulted
<asterite> In the new-fibers branch? That only works for x86_64 at the moment
<Kilo`byte> asterite: thats the code that causes it https://github.com/RX14/fast-irc.cr/tree/master/spec
<Kilo`byte> Crystal 0.7.6 [4570084] (Sa 22. Aug 15:22:19 UTC 2015)
<RX14> yeah
<asterite> But in a 32 bit linux, right?
<Kilo`byte> x86_64, linux
<Kilo`byte> for me
<asterite> Oh
<Kilo`byte> but it works for me
<RX14> yeah
<RX14> asterite, it's probably a 32-bit thing
<asterite> I tried it on mac and it "works" (specs fail) too
<Kilo`byte> RX14: crystal version?
<RX14> Crystal 0.7.6 (Fri 21 Aug 15:09:34 UTC 2015)
<Kilo`byte> asterite: yeah, the specs will have like 4 fails
<Kilo`byte> wait
<Kilo`byte> one fail is related to an index out of bounds
DeBot has joined #crystal-lang
<Kilo`byte> namely thr fourth one
<RX14> Kilo`byte, where?
<RX14> can you show me the specs
<asterite> I get a segfault on 32 bits too, in a VM
<asterite> Now it's time to reduce it :)
<RX14> okay
<RX14> if it's reproducable for ypou...
<RX14> i can get on with my coding
<Kilo`byte> 2 are fixed tho
<RX14> that's strange
<RX14> can you try and debug that index out of bounds?
<Kilo`byte> uh
leafybasil has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
<Kilo`byte> RX14: btw, current state
<Kilo`byte> (had to fiddle with my zshrc to get the stuff to work)
<RX14> Kilo`byte, can you fix #1 and #2
<RX14> they are emitting errors
<Kilo`byte> sure
leafybasil has quit [Ping timeout: 246 seconds]
<asterite> RX14: we usually use 2 spaces for indents, 4 spaces makes it really hard to read code because it soon gets too "righty"
<Kilo`byte> yeah
<Kilo`byte> that annoys me as well ;)
<RX14> i use 4
<RX14> deal with it
<RX14> if your code get "too righty" you need to split your stuff into a function
<RX14> thanks
<RX14> you're just waiting on me now :P
<Kilo`byte> also, i smell bad shit with using signal handlers due to usermode threads
<Kilo`byte> MAYBE we can hack around that with channels
<jokke> hi
<Kilo`byte> but it can bit us pretty easily
<jokke> how would i go about writing crystal bindings for a c++ library?
<Kilo`byte> jokke: best is to write c bindings first
<Kilo`byte> because c++ name mangling is compiler-dependant
<jokke> mmh ok
<jokke> i was afraid that'd be the way to go :/
<Kilo`byte> yeah, even if you did take the name mangling into account, with a different compiler (or even compiler version) that might break
<Kilo`byte> wouldn't rely on that
<Kilo`byte> jhass: can i force a certain routine to be run?
<Kilo`byte> without affecting the scheduled ones
<jhass> if you have a reference to it you can call .resume I guess
<Kilo`byte> that should do it
<jhass> asterite will hate me for telling you that though, he considers Fiber semi-internal :P
<asterite> RX14: I also get a segfault on 64 bits mac
<asterite> But... i can see this: prefix :: Prefix
<asterite> That's *unsafe*
<RX14> is it?
<RX14> oh dear
<BlaXpirit> kids these days, throwing around unsafe code and raw memory buffers
<asterite> So, if code uses unsafe features, segfaults are bound to happen
<BlaXpirit> while writing an IRC library
<BlaXpirit> just why
<BlaXpirit> WHYYYY
<jhass> BlaXpirit: make use of http://foaas.com/
<RX14> i didn't know
<RX14> i just thought it allocated space
<RX14> and it was a workaround for macros having a different context anyways
<asterite> Mmm... but I think you should trust LLVM more
<RX14> i'll try removing iy
<asterite> you are using macros just to make sure stuff gets inlined, but LLVM is pretty smart about this
<jhass> asterite: let's just have @[AlwaysInline] and point these kind of people to it ;)
<asterite> There's also the @[AlwaysInline] attribute, if you want to make sure of that... (though honestly I don't think it always inlines)
<RX14> i'm that kind of person now am I :P
<jhass> wait, it's already there?
<jhass> I grepped the source but only found it in some llvm enum
<RX14> oh yes prefix :: prefix was totally wrong
<RX14> I see now
<Kilo`byte> how do i trap a unix signal
<jhass> RX14: I do see some trust issues :P
<RX14> i thought it was always assigned but it's not
<jhass> Kilo`byte: Signal::FOO.trap
<RX14> no, it's my fault
<Kilo`byte> you should reflect that in the docs :P
<asterite> The `prefix :: Prefix` basically reserves memory for that struct, but uninitialized. So later if you forget to initialize one of the fields, unexpected things might happen
<RX14> yup that fixed the specs
<RX14> asterite, i realise that now, i'm just tired
<asterite> RX14: No worries. Maybe it's a mistake of the language that's it's so easy to write "x :: Int32"
<BlaXpirit> i think it is, asterite
knoopx has joined #crystal-lang
<asterite> maybe it should be more obvious that this is unsafe
<BlaXpirit> especially if the same is written in docs in comments everywhere
<RX14> i just thought of it as the same as String x; in java
<RX14> i knew it wasn't
<RX14> but in my tiredness i equated it
leafybasil has joined #crystal-lang
<RX14> how do I see what llvm is doing again?
<RX14> the optimisations
<Kilo`byte> jhass: can't i signal myself in the playpen? D:
<BlaXpirit> RX14, u wanna see the old message? [:04:39] <asterite> RX14: there's no need to trust LLVM, just do --release --emit llvm-ir (or llvm-bc, asm, or obj) and check the generated code ;0
<Kilo`byte> anyways, this is the code that might be viable for safe signal handlers
<jhass> Kilo`byte: never tried oO
<Kilo`byte> i assume it has exitcode 31 because i try using the blocked syscall kill
<jhass> yeah
<Kilo`byte> it does work locally
<asterite> Does someone have a snippet that shows what's the problem with signal handlers and IO?
<Kilo`byte> http://carc.in/#/r/cpl there, with output :P
<Kilo`byte> asterite: no, because you cannot reliably reproduce it
<Kilo`byte> actually even my code isn't safe
<Kilo`byte> because the Scheduler might try to do something else in the fiber thats currently being used for signal processing
<Kilo`byte> and hence not ready for whatever the scheduler might want
<Kilo`byte> i can't find the Queue class in the docs. does it even exist
<RX14> well it looks like the IRCv3 parsing is going to need a stringbuilder
<jhass> Kilo`byte: nope
<Kilo`byte> ic
<Kilo`byte> i can use an array
<jhass> Kilo`byte: https://github.com/jhass/DeBot/blob/master/thread/src/thread/queue.cr I'm not guaranteeing full correctness though :P
<jhass> (and it's not efficient, no linked list)
<Kilo`byte> even though i am passing data between fibers i must implement this myself
<Kilo`byte> i can't rely on the scheduler
<Kilo`byte> the scheduler could break everything
<jhass> well yeah, just use an Array perhaps
<Kilo`byte> i maaaaayyy have broken stuff
<Kilo`byte> the had a sleep 2 at the end
<Kilo`byte> it never managed to end that
<jhass> ah, good old could not raise :P
<RX14> i think my productivity is decreasing
<RX14> I will get ircv3 parsing working tomorrow I promise
<Kilo`byte> fixed, forgot to run Scheduler.reschedule https://gist.github.com/Kilobyte22/da289f4a96c0e44e2b1d
<Kilo`byte> RX14: heh, thanks :P
<Kilo`byte> jhass: i think i might look into integrating that into the standard lib
<Kilo`byte> so Signal.*.trap does all that in the background
<jhass> could be interesting, yeah
<jhass> you'll need a crashing testcase to convince asterite though I guess :P
<jhass> (of the current version)
<Kilo`byte> thing is: its a very unlikely race condition
<Kilo`byte> gonna be tough recreating that
<Kilo`byte> thing is: that testcase would probably crash the process if it triggered
<Kilo`byte> basicly you have to do something in the signal handler that causes Scheduler.reschedule to be run which then decides to run the fiber that is still handling the syscall
<Kilo`byte> actually not quite
<Kilo`byte> the fiber you run in has to be waiting for an operation
<Kilo`byte> and then that operation completes while the signal handler is still on the stack
<Kilo`byte> => undefined behaviour
<Kilo`byte> could crash the process, could act up, could do just about anything
knoopx has quit [Remote host closed the connection]
<jhass> I guess if you can make raise work "inside" signal handlers that's reason enough on its own :P
<Kilo`byte> jhass: see the issue? :P
<Kilo`byte> oh raise will work :P
<Kilo`byte> its all handled in a fiber dedicated for signal handling
<Kilo`byte> will still provide a low-level trap though
<Kilo`byte> that doesn't use this. this is if you need to get the stack for like, a segfault
<jhass> oh yeah, btw if you know a sane way to trap stack overflows...
<Kilo`byte> hmm
<jhass> all you'd need to manage there is print something to stderr and exit the process for now, that's be awesome already
<jhass> printing (part of) the stack where the overflow happened would be bonus
<Kilo`byte> well, if you manage to low-level trap it...
<Kilo`byte> jhass: my main reason for even doing this is that the other day i read about signal handling and now with the plan for an irc server which typically get reloaded etc using unix signals this actually might be an issue
<Kilo`byte> because it'd mean io (read: Scheduler.reschedule) in a signal handler
<Kilo`byte> after all i have to read all the config files - and if they are on a spun down disk and the signal happened in the thread os a user connection and that user sends anything... the server will crash
<Kilo`byte> or do whatever
<Kilo`byte> certainly not what it should
<jokke> how would i expose a constant from a c lib in my lib?
<Kilo`byte> in your lib block:
<Kilo`byte> $varname: Type
<Kilo`byte> like, an example from LibC: $errno: Int32
<jhass> jokke: "#define Constant" ?
oal has quit [Ping timeout: 260 seconds]
<Kilo`byte> wait, constant? uh idk
<BlaXpirit> jhass, no, that definitely doesn't work
<jokke> this is in the lib: https://p.jreinert.com/mGV4m/cpp
<jokke> so it's an enum after all
<BlaXpirit> jokke, it's just an enum, yeah
<jhass> BlaXpirit: it was meant as question to specify what constant means
<jokke> ok, no problem then
<BlaXpirit> oh sorry
havenwood has joined #crystal-lang
<jokke> yeah
<BlaXpirit> if something isn't there, that probably means that's not valid
<jokke> but i'm still not sure if i'm supposed to just basically copy the enum from the header to my lib
<BlaXpirit> by the way, I don't think you can just "expose" a constant, you need to just write the value as well
<jokke> ok
<BlaXpirit> same goes for this enum, it's safest to write these = 1 2 etc
<jokke> ok
<BlaXpirit> also there are programs that generate crystal bindings code for you. it's worth considering if the library is big
<jhass> I miss alias_method :/
BlaXpirit has quit [Quit: Konversation]
<Kilo`byte> integrated the signal stuff into the signal api
<Kilo`byte> will now test and possibly pull-request
<Kilo`byte> jhass: something exploded: Error in /usr/lib/crystal/compiler/crystal/tools/init.cr:6: already initialized constant Crystal::Init::WHICH_GIT_COMMAND
<Kilo`byte> during "crystal spec" in the compiler source tree root
* jhass shrugs
<Kilo`byte> make all_spec works
<jhass> weird
<Kilo`byte> anyways, as i see there isn't much specing on signal
<Kilo`byte> (kinda as expected)
<Kilo`byte> also compiling crystal is fuuuuun :P
<crystal-gh> [crystal] technorama opened pull request #1273: Implement deferred signal handling using libevent. (master...f/deferred_signals) http://git.io/vsyUX
<Kilo`byte> that looks like something i am doing atm
NeverDie has joined #crystal-lang
<Kilo`byte> jhass: what does a * mean in a spec run
<jhass> pending
<Kilo`byte> what does that mean for normal people?
<jhass> "deactivated test, should pass, does not yet"
<Kilo`byte> who don't know how exactly specs work
<Kilo`byte> ic
blue_deref has quit [Quit: bbn]
<jhass> Kilo`byte: so given you dived fairly deep into that stuff now, any clues why I might get this on 32bit after creating a bunch of fibers? http://paste.mrzyx.de/pura9d3gq
<Kilo`byte> also i just realized that Signal really needs more unittest
<Kilo`byte> even though the unit tests passed my implementation seems to have a bug
<Kilo`byte> first of all that sounds like a bug to me
<jokke> how do i namespace something in lib?
<jhass> jokke: mmh, don't think you can nest namespaces into a lib
<Kilo`byte> jokke: whatcha mean?
<jokke> i want to be able to define functions inside MyLib::Something
<jhass> guess you could abuse a struct
<jokke> hm
<Kilo`byte> one would have to compile libpcl with debug symbols
<jhass> I guess I could also just check the pointers passed to it in https://github.com/manastech/crystal/blob/master/src/fiber/fiber.cr#L24
<Kilo`byte> also wtf "==12746== by 0x6076FFF: ??? (in /dev/zero)"
<Kilo`byte> jhass: i think thats a good idea
<jhass> but I'm kinda too lazy to setup a 32bit environment where I can debug properly
<Kilo`byte> read: arch
<Kilo`byte> :P
<Kilo`byte> i've had issues with libpcl on debian based systems
<jhass> well, I even have a 32bit arch chroot..
<Kilo`byte> namely: getting it
<Kilo`byte> oh nice
<jhass> oh, and the error does happen on a 32bit arch machine
<jhass> but I also don't have a minimal test case
<Kilo`byte> 1_000_000.times { spawn { sleep 1000 } }
<Kilo`byte> does that work?
<Kilo`byte> i also vote for sleep without params
<Kilo`byte> def sleep; loop { sleep 1337 }; end
<jhass> been trying similar stuff, not with the loop though
<jhass> er, not with the sleep
bjmllr has quit [Read error: Connection reset by peer]
bjmllr has joined #crystal-lang
<jhass> nope, doesn't repro
<jhass> @stack = Pointer(Void)@0xbefd1000
<jhass> @stack = Pointer(Void)@0xffffffff
<jhass> that doesn't seem correct
<jhass> so I managed to let allocate_stack return garbage
<jhass> RSS stays below 70M, so I kinda doubt I exhausted any memory limits
<Kilo`byte> that doesn't sound good xD
<Kilo`byte> whats the difference between structs and classes
<jhass> pass by value vs pass by reference essentially
<jhass> structs are stack allocated afaik
<jokke> how do i turn a Uint8* to String?
<jhass> pass it to String.new
<jokke> ok
tatey_ has joined #crystal-lang
<jokke> hm
<jokke> i often have c functions in this lib that take an Gerror** as last param
<jokke> GError is a struct that i've also defined in my lib
<jhass> sounds like GObject based?
<jokke> yeah
<jhass> patch jhass/crystal-gobject to make it work for it? :P
<jokke> and i use one of those functions like this: the_function(foo, bar, out error)
<jokke> puts error tells me it's a pointer to GError
<jokke> so far so good
<jokke> i can't access the values of the GError though
<jhass> "can't access"?
<jokke> undefined method
<jokke> (for the pointer)
<jokke> so i tried dereferencing it with error.value
<jokke> and then i get segfaults when accessing the values
<jokke> error also is not nil
<jhass> did you check it's a null pointer?
<jokke> if checking means error == nil
<jokke> then yes
<jhass> no, it doesn't
<Kilo`byte> nah, error can be a pointer to 0
<jhass> nil != null
<Kilo`byte> you have to use .null? afaik
<jhass> crystal considers null pointers falsey actually
<jhass> >> puts "null" unless Pointer(Void).null
<DeBot> jhass: null - more at http://carc.in/#/r/cpt
<jokke> oh ok
<jokke> i see
<jokke> it's not null either
<jhass> then you mapped out the struct wrongly
shama has quit [Quit: (╯°□°)╯︵ɐɯɐɥs]
<jhass> let's see
<jokke> i guess so