<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
<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
<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
<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
<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
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
<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
<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
<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