00:43
Philpax has joined #crystal-lang
01:07
sp4rrow has joined #crystal-lang
01:08
pawnbox_ has quit [Remote host closed the connection]
01:40
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
02:16
Philpax has quit [Ping timeout: 246 seconds]
02:17
pawnbox has joined #crystal-lang
02:21
pawnbox has quit [Ping timeout: 240 seconds]
02:54
pawnbox has joined #crystal-lang
02:59
pawnbox has quit [Ping timeout: 258 seconds]
03:57
sp4rrow has joined #crystal-lang
04:06
willl has joined #crystal-lang
04:07
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
04:08
pawnbox has joined #crystal-lang
04:13
pawnbox has quit [Ping timeout: 252 seconds]
04:29
pawnbox has joined #crystal-lang
04:34
pawnbox has quit [Ping timeout: 258 seconds]
04:39
matp has quit [Remote host closed the connection]
04:40
matp has joined #crystal-lang
04:44
pawnbox has joined #crystal-lang
04:49
pawnbox has quit [Ping timeout: 250 seconds]
05:01
ponga has joined #crystal-lang
05:09
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
05:55
pochito has joined #crystal-lang
06:14
pawnbox has joined #crystal-lang
06:16
pochito has quit [Ping timeout: 250 seconds]
06:18
willl has quit [Quit: Connection closed for inactivity]
06:19
pawnbox has quit [Ping timeout: 240 seconds]
06:47
bjz has joined #crystal-lang
07:21
zodiak_ has quit [Ping timeout: 240 seconds]
07:24
pawnbox has joined #crystal-lang
07:28
pawnbox has quit [Ping timeout: 252 seconds]
07:28
sp4rrow has joined #crystal-lang
07:29
snsei has quit [Remote host closed the connection]
07:32
snsei has joined #crystal-lang
07:34
sp4rrow has quit [Quit: Textual]
07:38
toydestroyer has quit [Remote host closed the connection]
07:38
toydestroyer has joined #crystal-lang
07:40
zodiak has joined #crystal-lang
07:44
pawnbox has joined #crystal-lang
07:49
pawnbox has quit [Ping timeout: 276 seconds]
07:54
snsei has quit [Remote host closed the connection]
07:59
snsei has joined #crystal-lang
08:04
sandelius has joined #crystal-lang
08:09
pawnbox has joined #crystal-lang
08:11
trapped has joined #crystal-lang
08:17
snsei has quit [Remote host closed the connection]
08:23
trapped has quit [Read error: Connection reset by peer]
08:23
trapped has joined #crystal-lang
08:34
xaxes` has quit [Ping timeout: 250 seconds]
09:20
ponga has joined #crystal-lang
09:24
steenuil has quit [Ping timeout: 276 seconds]
10:06
steenuil has joined #crystal-lang
10:53
pawnbox has quit [Remote host closed the connection]
10:57
pawnbox has joined #crystal-lang
11:00
Philpax has joined #crystal-lang
11:14
Philpax has quit [Ping timeout: 244 seconds]
11:52
trapped_ has joined #crystal-lang
11:54
trapped has quit [Ping timeout: 240 seconds]
12:35
miketheman has joined #crystal-lang
12:36
miketheman has quit [Client Quit]
12:37
miketheman has joined #crystal-lang
12:40
miketheman has quit [Client Quit]
12:41
miketheman has joined #crystal-lang
12:51
bjz has quit [Ping timeout: 240 seconds]
13:00
bjz has joined #crystal-lang
14:07
Philpax has joined #crystal-lang
14:31
snsei has joined #crystal-lang
14:40
snsei has quit [Remote host closed the connection]
14:43
snsei has joined #crystal-lang
14:49
pawnbox has quit [Remote host closed the connection]
15:09
pawnbox has joined #crystal-lang
15:14
pawnbox has quit [Ping timeout: 258 seconds]
15:18
willl has joined #crystal-lang
15:25
trapped_ has quit [Read error: Connection reset by peer]
15:43
<
crystal-gh >
crystal/master 59ca015 Ary Borenszweig: Merge branch 'release/0.18'
16:01
Philpax has quit [Ping timeout: 246 seconds]
16:17
pawnbox has joined #crystal-lang
16:21
pawnbox has quit [Ping timeout: 240 seconds]
16:22
<
crystal-gh >
[crystal] mhib opened pull request #2917: Fix Char::Reader#pos documentation (master...master)
https://git.io/voHGi
16:28
<
crystal-gh >
crystal/master f5ebc44 Jonne Haß: Merge branch 'release/0.18'
16:29
<
crystal-gh >
[crystal] jhass closed pull request #2917: Fix Char::Reader#pos documentation (master...master)
https://git.io/voHGi
16:38
pawnbox has joined #crystal-lang
16:55
pawnbox_ has joined #crystal-lang
16:55
pawnbox has quit [Read error: Connection reset by peer]
16:56
qard has joined #crystal-lang
17:15
qard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
18:15
Raimondii has joined #crystal-lang
18:18
Raimondi has quit [Ping timeout: 240 seconds]
18:25
Raimondii is now known as Raimondi
18:38
<
RX14 >
jhass, i finished documenting SIzed and Delimited, what should be the namespace for the multipert stuff?
18:38
<
RX14 >
because it's not technically HTTP, it's mime
18:39
<
jhass >
but then we have no SMTP or idk no anything else where mime is used tbh
18:39
<
RX14 >
i think it would be acceptable to put it under http
18:39
<
RX14 >
but it is used in email too
18:39
<
jhass >
yes, we can still move it for some time when it starts to get used somewhere else
18:42
<
RX14 >
HTTP::Multipart::PullParser?
18:42
<
jhass >
I thought we decided against the pull parser interface?
18:43
<
RX14 >
i feel that it's the root interface everything can build on
18:43
<
jhass >
just HTTP::MultipartBody or so?
18:43
<
RX14 >
it's harder to build a reentrant parser on top of a block-based parser
18:46
<
jhass >
what do you mean?
18:47
<
RX14 >
if say we wanted to build a parser that needed to be a pull parser
18:47
<
RX14 >
it's harder to do that on top of a block based parser
18:48
<
jhass >
I don't follow which usecase your missing from yielding a IO::Delimited for each part
18:52
<
RX14 >
jhass, i just feel like it's not too hard to just make it a pull parser anyway
18:52
ruslux has joined #crystal-lang
18:53
<
jhass >
well by now I think it's too easy to write invalid code upon it
18:53
<
jhass >
and any valid usages I can come up don't benefit from such an interface
18:54
<
RX14 >
well what if someone wants a upll-parsed string-based interface
18:55
<
jhass >
I don't follow
18:55
<
RX14 >
what don't you follow?
18:56
<
jhass >
what a "pull parsed string based interface" is at all in this context
18:56
<
jhass >
some pseudo code might clear things up :)
18:57
<
RX14 >
if someone wants to have a pull interface to the parser where it returns string
18:57
<
RX14 >
instead of an IO
18:57
<
RX14 >
a pull parser is the lowest common denominator
18:58
<
jhass >
it's a gets_to_end call on the IO away....
18:58
<
RX14 >
yes but the block makes it hard
18:58
<
jhass >
the blocks makes it hard to write invalid code
18:59
<
jhass >
any valid code needs to consume the IO before getting the next one
18:59
<
jhass >
thus any valid code needs to store
18:59
<
RX14 >
it amkes it hard to make a non-block-based interface on top without using fivers
18:59
<
jhass >
.map(&.gets_to_end) #=> array of all parts as strings
19:00
<
RX14 >
yes but then thats not streaming
19:00
<
jhass >
I feel like you're ignoring my point :)
19:01
<
RX14 >
so what if it's eas to write code that produces an exception
19:01
<
RX14 >
you could say the same with slices sometimes
19:02
<
jhass >
this is already invalid
19:02
<
jhass >
and we have no way to raise
19:02
<
RX14 >
jhass, yes we do
19:02
<
RX14 >
the next call will close the image IO
19:02
<
RX14 >
meaning the image.read will throw
19:02
<
RX14 >
cause it's closed
19:04
<
RX14 >
we need to keep a handle to the old IO anyway to read it until the delimiter
19:04
<
jhass >
the next problem with the example it actually should handle order
19:06
<
RX14 >
jhass, yeah, well that doesn't have to do with that problem
19:07
<
RX14 >
i think we should make the actual parser a pull parser even if we :nodoc: it and make the only visible interface a block-based one
19:07
<
RX14 >
just because i think it's easier to make a lazy body parser that way
19:08
<
jhass >
I don't see how it's any easier?
19:08
<
RX14 >
because sometimes you want to read the response in bits
19:08
<
RX14 >
in different method calls
19:08
<
RX14 >
this way FORCES you to read all the parts in one block
19:09
<
RX14 >
you can't just say no i've found what i wanted but i might want to come back later
19:10
<
RX14 >
that requires you to write your code a certain way
19:10
<
jhass >
well, I'm not convinced of either I guess
19:10
<
RX14 >
there's nothing especially hard or dangerous about having it be a pull parser
19:11
<
RX14 >
the multi-fiber behaviour is the same as any other IO
19:11
<
jhass >
I can only repeat my point, it's terribly easy to write code that'll raise at runtime. A block based API makes it
_very_ obvious that storing the IO somewhere for later is a
_bad_ idea
19:12
<
RX14 >
and the closing the last stream returned when we call next means it's just going to throw
19:12
<
RX14 >
jhass, thats why I said make the main interface that
19:12
<
jhass >
well go ahead I guess
19:13
<
RX14 >
but some people want to do "dangerous" things, and I can think up of many use-cases the block-based model removes
19:13
<
jhass >
you'd buy me easier if you could come up with some more realistic usecase than "I might want to do something (what's this something?) else between reading two parts"
19:14
<
jhass >
so far you haven't provided one of those many usecases
19:14
<
RX14 >
a pull-based parser based on strings is entirely reasonable, but it's impossible to do effciently with the block based interface
19:15
<
RX14 >
you would need one fiber that writes the tuples from the block to a channel then the next method gets one form that channel
19:15
<
jhass >
I think I still have no clue what a "pull based parser based on strings" is in your mind
19:15
<
RX14 >
like the json pull parser
19:15
<
RX14 >
like the original idea
19:15
<
RX14 >
before streams
19:15
<
RX14 >
a pull parser that returns headers and body as a string
19:15
<
jhass >
whether i do that between two .next calls or within the block body, I don't see the difference
19:15
<
RX14 >
what we had before the bounded IO happened
19:16
<
RX14 >
jhass, the difference is that you can encapulate that in a class
19:16
<
RX14 >
and call next in two different method calls
19:16
<
RX14 >
a block-based interface only lends itself to the final consumer
19:16
<
jhass >
sorry I just don't understand you and I don't think I will without pseudo code
19:16
<
RX14 >
not any intermediate wrapper classes
19:16
<
jhass >
so either go ahead like I already said it'd be ok
19:17
<
jhass >
or if you do want to discuss it further I can only ask you for some pseudo code
19:25
<
RX14 >
how do you build an interface like that with a block?
19:26
<
jhass >
okay, that's convincing, thank you. However give me a minute I have a compromise
19:28
<
jhass >
consume & close the io in it's ensure
19:28
<
RX14 >
yeah i guess that works
19:29
<
RX14 >
it's the same thing anyway
19:29
<
jhass >
yes but discourages storing the io
19:29
<
RX14 >
yeah i guess a little
19:45
Raimondii has joined #crystal-lang
19:48
Raimondi has quit [Ping timeout: 240 seconds]
19:55
Raimondii is now known as Raimondi
20:12
<
RX14 >
jhass, did you benchmark your cicular buffer implementation?
20:12
<
jhass >
no, not yet
20:13
<
jhass >
I think I'd like to benchmark in something more real worldy, that is if I can just drop it into your finished multipart stuff
20:13
<
RX14 >
also, could you eliminate a memory copy by creating a slice that points to the single byte you want to read in the buffer and passing that to @io.read?
20:13
<
RX14 >
s/buffer/ring
20:16
<
jhass >
RX14: I don't think so?
20:16
<
jhass >
yeah I guess
20:20
pawnbox_ has quit [Remote host closed the connection]
20:20
pawnbox has joined #crystal-lang
20:26
<
jhass >
RX14: problem is I only want to copy the oldest ring value to the caller if there was a successful read
20:26
<
jhass >
and if I read to the ring directly I overwrite the oldest value
20:26
<
jhass >
mmh, or do I
20:27
<
jhass >
what did I get specs for, let's experiment a bit
20:28
<
jhass >
mh no that starts to skip stuff again on single byte reads by the caller
20:55
_jungh4ns has joined #crystal-lang
21:01
<
RX14 >
isnt that expected IO behaviour?
21:01
<
jhass >
it is, but sometimes documenting the obvious still makes things clearer ;)
21:01
<
jhass >
also not sure how well we handle missing closing codefences
21:02
<
jhass >
same suggestion for Sized
21:02
<
jhass >
but that should be enough otherwise :)
21:14
<
RX14 >
jhass, fixed
21:50
Raimondi has quit [Quit: All hail WeeChat 1.5-dev!]
22:01
<
RX14 >
jhass, is accessing class variable more expensive than local variables in crystal?
22:02
<
RX14 >
my java background is telling me it's expensive
22:02
<
jhass >
good question, I have no idea
22:02
<
jhass >
I would assume it's as expensive as accessing globals
22:02
<
jhass >
because that's what they are, namespaced globals
22:03
<
RX14 >
in high-performance java code methods often create local copies of class variables
22:03
<
RX14 >
that are used often
22:03
<
RX14 >
because it's that expensive
22:03
<
jhass >
well I'm not sure the JVM is comparable here
22:03
<
RX14 >
and my insticts tell me to do that in crystal bit it's probably wrong
22:03
<
jhass >
it has to keep them in some hashmap or so
22:03
<
RX14 >
i'm just so used to it heh
22:04
<
RX14 >
jhass, uhh, really?
22:04
<
RX14 >
the jvm does
22:04
<
RX14 >
i don't think that does either
22:04
<
RX14 >
the number of class variables are known when it allocates the memory
22:04
<
RX14 >
so it can just create a memory layout per class i expect
22:05
<
jhass >
well let it be a heap blob with known offsets
22:05
<
RX14 >
i think it does some special thread safety stuff idk
22:09
ruslux has quit [Ping timeout: 250 seconds]
22:24
<
RX14 >
ok well i have an untested implementation of multipart parsing with the new stream ops
22:24
<
RX14 >
just need to write specs now
22:27
qard has joined #crystal-lang
22:31
Philpax has joined #crystal-lang
22:34
Raimondi has joined #crystal-lang
22:44
Philpax has quit [Ping timeout: 246 seconds]
22:51
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
23:10
bjz has joined #crystal-lang
23:23
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]