00:01 <andrewrk> fine by me

00:03 <jfo> well,

00:04 <jfo> the closes I could come to your orange was https://www.hexcolortool.com/ec915c

00:04 <jfo> closest*

00:04 <jfo> so either one of those will work, it's up to you

00:12 <jfo> I pushed the orangish one https://github.com/github/linguist/pull/4005

00:14 <andrewrk> cool

00:21 <MajorLag_> is a ?&c_void returned by an extern fn treated specially? because it seems to behave differently than the same type as a field in an extern struct.

00:24 <MajorLag_> or as returned by a non-extern fn, for that matter

00:25 <andrewrk> can you elaborate?

00:26 <andrewrk> ?&c_void is not supposed to be special

00:27 <MajorLag_> well I was trying to put together a minimal test case when I realized extern might be a factor. Don't think I'll be able to do that before I have to go though. Basically, if I call SDL_malloc I can do things with the result that I can't do with SDL_Surface.pixels. Specifically, I can cast it to a slice without a @ptrCast. If I return ?&c_void from a native fn (a fake malloc), I can't use ?? with it, but I can do that with SDL_malloc.

00:30 <andrewrk> hmm I'll have to poke around with this

00:34 <MajorLag_> error: slice of non-array type '?&c_void' is the error I get with SDL_Surface.pixels, error: incompatible types: 'void' and '&c_void' with fake malloc, even though the return type is explicitly ?&c_void.

00:40 <andrewrk> it looks like you need to handle null

00:40 <andrewrk> I gotta go AFK. feel free to file a bug and we'll get it sorted out one way or the other.

06:46 <tiehuis> by the way, working casually on a regex engine in zig. i've got a rudimentary parser/compiler/vm right now, might have something decent in a month or so.

06:46 <tiehuis> anyone had any pressing need for regexes yet?

07:58 <MajorLag_> andrewrk: so yeah, it wasn't a bug. I just didn't realize that it's behaving differently because the type I was slicing was actually &c_void, having been unwrapped by ??. However, I think I found a bug while working that out, which I've submitted.

08:04 <tiehuis> that error was actually fixed earlier today

08:06 <tiehuis> if you pull the latest you should be okay

08:08 <MajorLag_> Just my luck

08:09 <MajorLag_> I see why I didn't find it by searching for "extern"

08:10 <tiehuis> yeah, unlucky too that you were only one commit behind!

08:10 <jfo> tiehuis: I was just thinking about regexes last night! what flavor are you using?

08:12 <tiehuis> perl style I believe, although using a dfa approach so no backreferences and things

08:13 <tiehuis> i haven't fleshed out much yet, still need to flesh out some of the compilation and do some refactoring

08:33 <jfo> what is "dfa"?

08:34 <jfo> is it this dfa? https://en.wikipedia.org/wiki/Deterministic_finite_automaton

08:38 <tiehuis> yes

08:38 <tiehuis> here a great set of articles outlining how it works: https://swtch.com/~rsc/regexp/regexp1.html

08:39 <tiehuis> pretty much what i'm basing everything on and it's what a few other languages like go, rust have followed pretty closely

09:08 <jfo> cool, thanks for that link. lmk when it's on gh so I can take a look at it!

09:22 <jfo> tiehuis: this article is v good

09:23 <jfo> I appreciate how concise it is

21:22 <andrewrk> tiehuis, regex engine, that's exciting

21:22 <andrewrk> I have an idea for a use case

21:23 <tiehuis> what use case?

21:23 <andrewrk> you list a bunch of HTTP endpoints with regex, and the engine combines them into one master regex that dispatches accordingly

21:24 <andrewrk> for example, something like: addUrl("/user/(\d+)", handleUserFn); addUrl("/song/(\d+)", handleSongFn);

21:25 <tiehuis> right, i see

21:25 <andrewrk> idea being that instead of doing 2 regexes, at compile time it creates 1 regex

21:25 <andrewrk> this might be very difficult to achieve. I don't really know where to start

21:25 <tiehuis> you can actually do that in linear time fairly efficiently as you can combine regexes into a single automaton

21:26 <tiehuis> i.e https://doc.rust-lang.org/regex/regex/struct.RegexSet.html

21:26 <andrewrk> ooh

21:26 <tiehuis> although sorry this only allows you to know if one of those match

21:26 <tiehuis> so you wouldn't be able to dispatch in this case

21:27 <tiehuis> i know that fast routers in go typically use a radix trie, which we could compute at compile time

21:27 <tiehuis> those routers though usually are more limiting in their matching, however

21:28 <tiehuis> also would be really cool to be able to get regex construction at compile-time for free

21:28 <tiehuis> think the only thing blocking this right now is the ability to use allocators at compile-time

21:30 <tiehuis> just going back to the regex group construction, if we had good enough regex simplification you could just construct one big regex of the alternation of all the routes

21:30 <tiehuis> and then rely on the engine to simplify common literal prefixes

21:36 <andrewrk> tiehuis, I think we can solve the allocators at compile time problem

21:38 <andrewrk> not sure how to hook it up yet, but you should be able to allocate static storage with a comptime known size

21:50 <andrewrk> maybe we could have @comptimeAllocate() and then we could use that to create a mem.Allocator at comptime and pass that to a function

21:51 <andrewrk> I think this should work

23:32 <GitHub156> [zig] andrewrk pushed 1 new commit to master: https://git.io/vNDTn

23:32 <GitHub156> zig/master f66ac9a Andrew Kelley: fix crash when align 1 field before self referential......