#(AoC) dynamic loading?

1 messages · Page 1 of 1 (latest)

errant swallow
#

In my main.zig, I have code like the following:

const problems = [_]aoc.ProblemFn{
    @import("./p01.zig").problem01, // 0: ignored entry
    @import("./p01.zig").problem01,
    @import("./p02.zig").problem02,
    @import("./p03.zig").problem03,
    @import("./p04.zig").problem04,
    @import("./p05.zig").problem05,
    @import("./p06.zig").problem06,
};

is it possible to make this dynamically discovered? (the functions can all be renamed to something generic to make it more uniform)

dreamy nimbus
errant swallow
#

Happy to do so but couldn't figure that out... I thought you link to your "main" / top level and then it figures the rest of the dependencies out via the @import reachability?

dreamy nimbus
#

I think I might need to make an example lol
it's not hard to explain, but I think longplace people will use it as reference, since AoC is one of those where this is actually nice to do

errant swallow
#

I was assuming I'd have to do some comptime initialization of the above

#

I can't even find anything globby tho... so... bleh. I'm using the wrong words

dreamy nimbus
#

It's file stuff == not pure == not comptime

#

not pure as in: need syscalls

#

Basically build.zig is just a zig file, so you can use the file api to explore a folder, create a file that has all the references it needs and finally import that as a package

#

with exe.addPackage

#

but let me example that since is a bit hard to understand for some, and is a commonly asked question

errant swallow
#

nods

dreamy nimbus
#

Has quite a few steps

#

in build.zig I do discovery and generation of the new package

#

in main.zig I run the functions

errant swallow
#

good god.

dreamy nimbus
#

in solutions I have in each file firstSolution and secondSolution functions which are called and "autodiscovered" in the package

errant swallow
#

goes to show how badly glob is needed... at the very least

dreamy nimbus
#

Not really

#

Glob is not great imo

#

but that's my take lol

#

mind, I use ruby haha

hoary oar
dreamy nimbus
#

is a special case when this is useful

errant swallow
#

Dir["src/p*.zig"].each { |f| require f } would be lovely right about now

#

interesting that you're literally writing out zig code to do this... I wouldn't have thought that necessary. I kept looking for something in Builder to addFile or somesuch but they never worked out the way I thought they would

hoary oar
#

no reason for addFile

dreamy nimbus
#

Code Generation shruggin

hoary oar
#

each zig source tree is a full project

#

which of the files is your root file then?

errant swallow
#

src/main.zig

hoary oar
#

but why?

#

its an arbitrary name and location

errant swallow
#

but why what? I'm pretty sure I'm not following at this point

hoary oar
# 
zig build-exe foo.zig bar.zig
#

which of these files will provide the entry point for your applicatio ?

errant swallow
#

I started with zig init-exe and went from there.

hoary oar
#

in zig, we solve this question by only allowing a single file

hoary oar
dreamy nimbus
#

I am doing basically scripting there

hoary oar
#

as zig only knows local namespaces files must form a explicit graph structure

errant swallow
#

yes and no... build.zig also is shaping the community around standards...

    const exe = b.addExecutable("x", "src/main.zig");

that might be arbitrary, but it is probably 90% of the projects out there at this point
(how does discord not have ^t for transpose?!?)

hoary oar
#

you cannot add two filea as a root as the stdlib would not be able to infer which one you want to use

#

and as that would be an ambigious thing, zig doesnt allow it

errant swallow
#

I'm not suggesting addFile should add a file as a root... I'm suggesting it should be able to add code in general. addExecutable (and kin) can define the root

hoary oar
#

that still doesnt make sense for zig

#

"adding a file" will literally do nothing

dreamy nimbus
#

The build system is just an extension from zig

errant swallow
#

without something like that, well, you generate code by hand and add a package and and and...

hoary oar
hoary oar
dreamy nimbus
hoary oar
#

thats basically a goal

#

as its explicit

#

zig doesnt like implicit convenience behaviour at all

#

convenience is made by tooling, not by the language

dreamy nimbus
#

Two examples that comes to mind
C# Source Generators - Generate files with code based on reading the source code
C code generators - Well that 😄

errant swallow
#

no, you haven't... C makefiles glob just fine, for example. Many systems out there could handle an arbitrary amount of input.

The only thing I'm seeing build.zig doing that's "different" is being the boundary between safe/known/static and not

hoary oar
#

its a basic philosophy of zig (language) to only do what's really necessary

dreamy nimbus
hoary oar
#

in that regard

#

in C, files form a soup of symbols

errant swallow
#

yeah, I know. I am providing counterexamples to "we have been doing this forever in all languages"

hoary oar
#

in zig, files form a structured graph of decls

fallow dock
#

we have been doing it forever in all languages, but while hiding all of the details

dreamy nimbus
fallow dock
#

hidden things have hidden costs, and that is in opposition to zig's design philosophy

#

zig is first and foremost meant to be readable, and after that, it is meant to be writable

flat folio
#

is it possible to make this dynamically discovered?
no

errant swallow
#

yeah... and I get and appreciate that. In this specific case, I'm gonna say that the solution provided is NOT readable (by my standards) so I'm gonna stick to my original static @import setup even tho it's a bit of pain

dreamy nimbus
#

Yeah, and that's fair lol

fallow dock
#

I'd say the original static import setup is pretty readable lol

dreamy nimbus
#

I provided one solution, and did not expect to be THE solution, it's just dumb fun

errant swallow
#

yeah fair.

dreamy nimbus
#

and also answering the question of: How you do this dynamicly

hoary oar
errant swallow
#

curious why you made ValidExtension as an enum? I see below how you're using it. It that just a strange way to avoid std.mem.eql ?

dreamy nimbus
dreamy nimbus
hoary oar
errant swallow
#

yeah... I think extracting my list from main.zig to it's own file... then write that out (prolly via a Rakefile for now, ironically)

dreamy nimbus
#

when I first did AoC I thought on doing something like that

#

decided it was easier just calling them similar and using multiple cursors

#

lol

errant swallow
#

multiple cursors?

dreamy nimbus
#

Editor feature

#

You can just write the same text in multiple places at the same time

errant swallow
#

oh derp. sure

#

@hoary oar I'm trying to find use of your standard-controls.zig in the project and coming up short. I was hoping to find a pattern for shared definitions across multiple impl files

#

but it looks like standard-controls is only referenced explicitly in build.zig

dreamy nimbus
#

The idea is to:

const standard_controls = @import("standard-controls");
#

and you use it in your code

#

That's my haven't used zero-graphics guess

errant swallow
#

I'm hoping usingnamespace might come to my rescue, but based on my experiments that looks to not be the case. IDGI because it says it must go into a struct/enum/whatever but every file is an implicit struct so I thought it would Just Work™

hoary oar
#

standard-controls.zig is a package