<< 07-07-2017 >>
00:01:57*Guest56511 quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:13:08*Matthias247 quit (Read error: Connection reset by peer)
00:42:13*Elronnd is now known as ArthurDent
00:42:30*ArthurDent is now known as Elronnd
00:45:36*yglukhov joined #nim
00:50:16*yglukhov quit (Ping timeout: 260 seconds)
01:20:20*v17d quit (Remote host closed the connection)
01:21:03*v17d joined #nim
01:33:44*chemist69_ quit (Ping timeout: 255 seconds)
01:47:45*chemist69 joined #nim
01:58:48*v17d quit (Remote host closed the connection)
02:34:15FromGitter<zacharycarter> o/
02:37:47*pilne quit (Quit: Quitting!)
02:53:43*def-pri-pub joined #nim
03:17:16FromGitter<Varriount> Hey @zacharycarter!
03:17:54FromGitter<zacharycarter> Hi Varriount!
03:17:59FromGitter<zacharycarter> @Varriount sorry
03:18:33FromGitter<zacharycarter> how's it going bud?
03:20:44FromGitter<Varriount> Super busy. I've been taking longer than required on my game dev assignments, as I can't resist re-writing the (simple but messy) code.
03:21:11FromGitter<zacharycarter> :D
03:21:16FromGitter<zacharycarter> what language?
03:22:19FromGitter<Varriount> C++
03:22:38FromGitter<zacharycarter> yuck
03:22:42FromGitter<Sud0nim> Hi guys, this is probably a silly question - but I am looking at the reddit daily programmer problem here: https://www.reddit.com/r/dailyprogrammer/comments/6l3hd8/20170703_challenge_322_easy_all_pairs_test/ and can't work out how to make a sequence of unknown size sequences. As an example one of the inputs for the questions is of the format @[['0', '1'], ['A', 'B', 'C'], ['D', 'E', 'F', 'G']] - but I can't work out
03:22:42FromGitter... how to initialise it
03:22:52FromGitter<Varriount> I would do it in Nim, had I the option - the library we're using is Allegro, which could probably be very easily wrapped.
03:23:08FromGitter<zacharycarter> yeah allegro is a pretty old / but popular lib
03:24:29FromGitter<Varriount> @Sud0nim Well, you can either use `newSeqtype (size)` to create a sequence of that size with empty/null elements
03:24:53FromGitter<Varriount> Or you can create an empty sequence and use the 'add' procedure.
03:27:16FromGitter<Sud0nim> Thanks, I'll give the add proc a try
03:31:54FromGitter<Sud0nim> var inputs = newSeqWith(0, newSeqchar (3)) ⏎ ⏎ inputs.add(@['0', '1']) ⏎ inputs.add(@['A', 'B', 'C']) ⏎ inputs.add(@['D', 'E', 'F', 'G']) [https://gitter.im/nim-lang/Nim?at=595f00a93230e14f3a3359f7]
03:32:00FromGitter<Sud0nim> worked for me, cheers Varrimount
03:32:48FromGitter<Sud0nim> var inputs = newSeqWith(0, newSeqchar (3)) <- sorry it didn't copy some of the brackets across correctly
03:35:39*rauss joined #nim
03:37:06FromGitter<Sud0nim> Just out of curiosity, is there any way that the compiler can infer the sequence type /length by writing something like:
03:37:15FromGitter<Sud0nim> var inputs = @[['0', '1'], ['A', 'B', 'C'], ['D', 'E', 'F', 'G']]
03:37:46FromGitter<Sud0nim> or is it always required to do something like adding to the empty sequence? Thanks
03:54:39FromGitter<zacharycarter> strange
03:54:44FromGitter<zacharycarter> getting weird errors trying to initialize opengl now
03:55:28FromGitter<zacharycarter> oh I'm being stupid nevermind
04:05:53*def-pri-pub quit (Quit: Lost terminal)
04:06:52shashlickVarriount: can this issue be closed? https://github.com/nim-lang/Nim/issues/1818
04:13:52subsetparkSud0nim - you can absolutely declare seqs by instantiating them directly; that particular example would fail type checking because the seq is not homogeneous; arrays are typed by their length and so the elements of that example are of different types
04:16:03*rauss quit (Quit: WeeChat 1.9)
04:36:29FromGitter<Sud0nim> Ah, yes I see. Thanks for clarifying. I guess I will probably use the add method for now, as I don't want to put in some sort of dummy char like: var inputs = @[['0', '1', 'a', 'a'], ['A', 'B', 'C', 's'], ['D', 'E', 'F', 'G']] to get them to be the same length. Thanks for both of your help
05:03:26*Snircle quit (Ping timeout: 255 seconds)
05:40:16FromGitter<Araq> @Sud0nim I think you're looking for @[ @["nested", "seq", " of strings"], @["ab"] ]
05:51:39shashlickIs it possible to statically link pcre on Windows?
06:01:34*tankfeeder joined #nim
06:06:26FromGitter<mratsim> In the Nim manual, in the concept section, there is this example: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Shouldn’t `s` be `var s` otherwise how can it be popped? [https://gitter.im/nim-lang/Nim?at=595f24e23230e14f3a33d98b]
06:08:30FromGitter<Araq> yeah, it should be 'v' instead of 's' here
06:25:10*abeaumont quit (Ping timeout: 276 seconds)
06:28:08*skrylar joined #nim
06:38:29*Kingsquee joined #nim
06:39:46FromGitter<Sud0nim> @Araq Perfect, I was sure I tried that but I must have missed an @ symbol on the first seq: let x = @[['0', '1'],... instead of let x = @[@['0', '1'],... I had a feeling Nim would have an easy way to do that
06:47:56*nsf joined #nim
06:52:44*Trioxin joined #nim
06:53:33*adeohluwa joined #nim
06:53:35Trioxinwhat would be the ideal method for monitoring for a volume being mounted?
07:00:32skrylarthis is os specific behavior
07:01:16skrylarsometimes even distro dependent (on linux) given that gnome has a virtual filesystem thing that handles it, i think KDE has another
07:02:12skrylarOn the nim side, probably just a signals and slots setup where you can be like "on_volume.mounted do (v: volume): ..."
07:02:29skrylarOr just a procvar if you don't need multiple subscribers
07:02:32*tankfeeder quit (Quit: Leaving)
07:06:24*rokups joined #nim
07:10:49*arnetheduck joined #nim
07:12:02*xet7 joined #nim
07:17:18*yglukhov joined #nim
07:21:16*yglukhov quit (Remote host closed the connection)
07:22:37*yglukhov joined #nim
07:22:41*yglukhov quit (Remote host closed the connection)
07:22:57*yglukhov joined #nim
07:29:27*yglukhov quit (Remote host closed the connection)
07:42:41*couven92 joined #nim
07:44:58*yglukhov joined #nim
07:54:22*Arrrr joined #nim
07:57:22*shashlick quit (Quit: Connection closed for inactivity)
08:05:58*gokr joined #nim
08:07:29*tankfeeder joined #nim
08:25:35*abeaumont joined #nim
08:40:12*skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…)
08:52:30*skrylar joined #nim
08:52:30*skrylar quit (Client Quit)
09:07:38*bjz joined #nim
09:09:25*Trustable joined #nim
09:20:46*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
09:37:35*gokr quit (Read error: Connection reset by peer)
09:40:14*bjz joined #nim
09:48:10*v17d joined #nim
10:13:49*Vi- joined #nim
10:15:24*arnetheduck quit (Ping timeout: 260 seconds)
10:23:46*krux02 quit (Remote host closed the connection)
11:07:01*salewski joined #nim
11:07:40salewskidom96, for https://forum.nim-lang.org/t/3031
11:08:32salewskiit seem that it only works with "nimble prepare" followed by "nimble install".
11:09:06salewskiBut does "nimble prepare" task work at all for remote packages?
11:09:27salewskiThat is not very clear from the github nimble readme.
11:10:48salewskiI think for users it would be ok to type two commands -- when it works at all. But of course they may try only "nimble install"
11:11:10salewskiwhen they do not read the docs.
11:12:21salewskiWhen you think that "nimble prepare" will work for the remote reposity, than I think I can push it to github and publish it.
11:12:26*Matthias247 joined #nim
11:12:52salewskiWhen not -- well then I have no idea currently...
11:17:20*Snircle joined #nim
11:21:50Araqsalewski: I don't understand your "install-only dependencies"
11:22:27Araqcan you explain a bit more? why is the low level gtk-3 wrapper from yours requires only for installation and not for building the software?
11:23:27*v17d quit (Ping timeout: 268 seconds)
11:24:16*Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif)
11:24:41*Vi- quit (Ping timeout: 268 seconds)
11:27:27*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
11:35:27salewskiAraq, my generator script is called gen.nim. To compile that, I need the low level ngtk3 3.20 bindings.
11:36:17Araqok, so only the generator needs that?
11:36:37salewskiWhen that it compiled, I do not need the ngtk bindings any more. Then I execute ./gen and that program reads the gobject inrospection data
11:36:54salewskiand generates the true high level bindings.
11:37:06Araqhmm and the output of ./gen can't be put in the repo?
11:37:13Araq*into the repo
11:38:17salewskiNo, the output of gen depends on the local computer, it is different for 32 and 64 bit, different for installed GTK version, diffeent for windows...
11:38:58salewskiAll what we have i the low level bindings expressed with when clause do the gintrospection not offer.
11:39:33salewskiIt is specific for the current box. So we had to ship many different versions of the modules.
11:40:18salewskiAnd as I told a few times, I myself can only provide files for Linux 64 bit.
11:40:58salewskiI could provide versions for older GTK still. But not for 32 bit system, not for Windows, not for mac
11:42:08salewskiAnd as I told already, later when we have many users, they may provide tested files for specific system, but that would be more a fallbacl.
11:42:26Araqyeah sure
11:43:11salewskiIt is similar as the nim compiler, we need some bootstrapping. Bootstrapping could later start with high level bindings,
11:43:12Araqhow much of ngtk3 is required for gen.nim to work?
11:43:33salewskibut still we need something to start from. Or ship binary executables.
11:43:43Araqyou could copy the relevant sections from ngtk3 to gen.nim
11:43:55Araqif it's not too much stuff that you need from it
11:44:24salewskiAll the modules I specify, I have already removed the unnecessary gtksourceview.
11:45:17salewskiYes, I could try to select only the data types and procs from source code that are currently needed.
11:45:41Araqwell I dunno, copying code is not great
11:45:50salewskiMuch work, and the work is not final yet, whenever I improve the genrator, I may need new procs.
11:46:07Araqyeah, let's wait for dom96's response
11:46:17Araqinteresting problem.
11:46:32salewskiI think all that is fine.
11:47:03salewskiProblem is not bootstrapping, problem is executing generator program before installing.
11:47:38salewskiBecause I generate bindings from gobject-introspection before that modules are installed.
11:48:32salewskiThat is how gobject-introspection works, interpreted languages generate bindings even on the fly.
11:49:16salewskiBey, will read logs later...
11:49:20Araqbye
11:49:27*salewski quit (Quit: WeeChat 1.4)
12:03:04*krux02 joined #nim
12:10:09FromGitter<zacharycarter> o/
12:14:13*salewski joined #nim
12:15:25salewskiAraq, dom96: just a short note:
12:15:25salewskiYou may be rigth that for bootstrapping I do need less modules from low level ngtk3.
12:15:48salewskiI need glib, gobject, gir of course, but maybe not all the others.
12:16:47salewskiBut that makes not really a difference, I have to bootstrap from ngtk3, and I have to execute the gen script before I can do nimble install.
12:17:37salewskiIt only saves some internet bandwith, I will see tonight which modules of ngtk3 are unneeded.
12:18:36salewskiAnd generally nimble would already support it, the before kook exists, but from issue tracker it seems not to work properly.
12:18:42salewskiBye.
12:18:53FromGitter<zacharycarter> @gokr the atomic game engine community seems less than thrilled with the idea of a Nim wrapper around Atomic
12:19:21FromGitter<zacharycarter> @gokr but atomic also seems to be more feature-rich than Urho3d
12:19:30FromGitter<zacharycarter> either way it seems like a ton of work, which I'm not sure how to proceed with
12:20:11FromGitter<zacharycarter> I've never done any C++ interop with Nim before and I don't quite understand how it's done, I've only done C interop
12:20:17*salewski quit (Quit: WeeChat 1.4)
12:20:35FromGitter<zacharycarter> I don't see why we couldn't together (as a community) build something like raylib with Nim
12:20:46FromGitter<zacharycarter> which I think would serve as a great starting point for any 2d / 3d game project
12:26:13*Jesin quit (Ping timeout: 240 seconds)
12:39:20*Jesin joined #nim
12:40:57Araqanyone with experience with libCEF around?
12:52:11*Arrrr quit (Read error: Connection reset by peer)
12:54:43*FromGitter * zacharycarter is curious what you're doing with cef
13:01:53Araqporting karax to native code
13:02:24Araqbut ugh, libCEF's DOM has no methods like a web's DOM
13:06:59*sdw left #nim (#nim)
13:11:22FromGitter<zacharycarter> oooo
13:13:17*adeohluwa quit (Quit: Connection closed for inactivity)
14:00:27*couven92 quit (Quit: Client disconnecting)
14:02:52FromGitter<Varriount> @zacharycarter Well, you could try making a C wrapper around Atomic, or wrap it directly
14:04:17FromGitter<Varriount> The problem with C++ is that C2Nim has a much harder time of parsing it (especially in template-heavy code bases). Nim's importcpp feature is fairly complete though.
14:04:39*Vi- joined #nim
14:05:00AraqIME C++ vs C makes no difference for c2nim. it works equally bad/well depending on project specific code style only.
14:07:29Araqboth languages are equally impossible to parse without a symbol table. C++'s parsing complexity over C is a myth IMO.
14:08:04FromGitter<Varriount> Araq: I've found C2Nim's C++ mode to be much more difficult. I still haven't figured out how to get it to parse libtorrent's source code. It always chokes at "namespace libtorrent {"
14:08:35Araqlol, maybe I never implemented "namespace" ?
14:10:10AraqI stand by my words anyway. C's declaration syntax is a mind blowing clusterfuck and C++'s templates are tame in comparison
14:12:51Araqnamespace Urho3D {
14:12:59Araqis part of the test suite
14:13:03Araqand works
14:13:28*tankfeeder quit (Quit: Leaving)
14:13:40Araqyou need to use c2nim --cpp though, c2nim is stupid and doesn't do file ending based language detection
14:15:50*yglukhov quit (Remote host closed the connection)
14:16:50*yglukhov joined #nim
14:20:44FromGitter<Varriount> Oh yuck, libtorrent uses bitfields
14:21:19FromGitter<Varriount> How does one even wrap structus containing bitfields?
14:26:28euantorVarriount: https://github.com/euantorano/serialport.nim/blob/master/src/libserialport/private/serial_windows.nim#L9
14:26:39euantorLike that :)
14:27:00*skrylar joined #nim
14:37:42*skrylar quit (Read error: Connection reset by peer)
14:42:06*skrylar joined #nim
14:46:21Araqc2nim can handle bitfields iirc
14:47:36*shashlick joined #nim
14:48:32*skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…)
14:48:58*skrylar joined #nim
14:49:47*couven92 joined #nim
14:54:14FromGitter<TiberiumN> can I create an alias for "echo"?
14:54:21FromGitter<TiberiumN> like ⏎ ⏎ ```let something = echo``` [https://gitter.im/nim-lang/Nim?at=595fa09d2723db8d5ee9cdb8]
14:54:31FromGitter<TiberiumN> and use something as echo
14:58:49*skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…)
15:11:41FromGitter<ephja> @TiberiumN try const instead
15:13:07koppehMhh.. I've redone my nim setup in hopes of fixing some strange errors compiling the std.
15:13:31koppehSo I got msys2 and set it up, then grabbed nim fresh.
15:14:15koppehCurrently it's showing the error "ld.exe: cannot find -l<library>" even though the libraries are in our project folder.
15:15:00koppeh--clib: "../lib/glew" and "/opengl32"
15:15:31koppehglew32*
15:19:24FromGitter<ephja> the working directory is not part of the default path
15:19:56koppeh--clibdir seemed to have gotten rid of the first missing library..? Or it will complain later.
15:21:40yglukhovAraq: what do you think about supporting try: yield in closure iters?
15:23:08yglukhovapart from supporting closure iters in js ;)
15:24:25FromGitter<ephja> koppeh: --clibdir:.?
15:26:38koppehI .. think I need to include wherever opengl is located in my nim cfg..?
15:26:58koppehI'd imagine mingw includes those my default? Heck if I knew..
15:28:05FromGitter<ephja> it should include the equivalent of /usr/bin
15:28:21FromGitter<ephja> *lib
15:29:17koppehI suppose that'd be msys2/usr/lib ?
15:29:39koppehDoesn't include opengl32.lib, I found it in the Windows SDKs..?
15:29:45Vi-I had to include them by hand with --clib (msvc)
15:29:48koppeh(I really have no idea what I'm doing, for the record.)
15:29:53Vi-So I have
15:29:55Vi---clib: "../lib/glew32"
15:29:55Vi---clib: "/opengl32"
15:30:11Vi-and that finds them somehow
15:31:31koppeh--clibdir: r"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.15063.0\um\x64"
15:31:32*tankfeeder joined #nim
15:31:42koppehThis fixes the missing opengl thing.
15:31:58koppehBut the one in our project folder it can't find.. for some reason?
15:32:27Vi-well it doesnt find "/opengl32" then
15:32:34Vi-Which was really odd to begin with
15:32:39koppehNo, ../lib/glew32 is missing.
15:32:52Vi-but thats how I got around having to include that path
15:36:01Vi-Some other thing that happened to me was when I tried to pass linker options it ended up passing it to the compiler (which gently ignored the option) and then to the linker again
15:42:52*Guest68663 joined #nim
15:44:39*Guest68663 quit (Client Quit)
15:47:52*v17d joined #nim
15:51:22*salewski joined #nim
15:52:36salewskiAraq, your where right, I need only the 3 modules glib, gobject and gir from legacy ngt3 repository for bootstrapping.
15:53:17salewskiI have corrected that in my forum post, looks a bit cleaner now.
15:54:04salewskiBut tht changes NOTHING for all my mentioned problems, it only saves some internet bandwith for install process.
15:55:02salewskiThat I needed only 3 modules was a bit surprising for me, because when I use the main module gtk, then I also need all the others
15:55:59salewskibut gtksourceview. But as the gen.nim program is not graphical at all, it is not surprising that we need not gtk module.
16:07:26*NimBot joined #nim
16:07:44*tankfeeder quit (Ping timeout: 268 seconds)
16:09:27FromGitter<zacharycarter> meh I still think Nim would be better served with a better version of something like FRAG / raylib
16:09:42FromGitter<zacharycarter> than spending months wrapping and keeping a wrapper up to date for atomic
16:11:33FromGitter<zacharycarter> I know Urho3d / atomic has features that raylib doesn't - like skeletal animation, PBR, etc
16:11:50FromGitter<zacharycarter> but those things can be added later, for instance raylib has a pbr module built on top of it
16:16:09*yglukhov quit (Remote host closed the connection)
16:18:48*yglukhov joined #nim
16:21:52*cspar joined #nim
16:22:25FromGitter<Varriount> But c2nim won't
16:24:01*cspar_ quit (Ping timeout: 248 seconds)
16:24:13FromGitter<zacharycarter> won't what?
16:25:07*yglukhov quit (Ping timeout: 276 seconds)
16:34:03Vi-I have a few functions which share the same signature, now I want to create a variable that points at one to them
16:34:08Vi-let foo: FunctionType = myFunction
16:34:09Vi-this works
16:34:18Vi-let foo: array[1, FunctionType] = [myFunction] this doesnt
16:34:27Vi-But this does: let foo: array[1, FunctionType] = [FunctionType(myFunction)]
16:34:32Vi-Is that intended behavior?
16:36:45Vi-FunctionType is a typedef ofc
16:50:28FromGitter<mratsim> Is there a way to have nim doc/doc2 follow includes ?
17:03:42*yglukhov joined #nim
17:07:28*Matthias247 quit (Read error: Connection reset by peer)
17:08:05*yglukhov quit (Ping timeout: 240 seconds)
17:12:18koppehVi- is using msvc and the same setup isn't working for her.
17:12:40koppeh--clibdir appears to be ignored and the --clib provided afterwards not found..?
17:14:15*nsf quit (Quit: WeeChat 1.7.1)
17:14:27koppehThis should be translated to the proper arguments (/LIBPATH?) and work, right?
17:14:48koppeh--clibdir: "../lib/"
17:14:50koppeh--clib: "/glew32"
17:15:41Vi-ye I need to do
17:15:42Vi---clib: "../lib/glew32"
17:15:46Vi-and clibdir does nothing
17:18:06subsetparkVi-: I can reproduce that... I'm not sure why that should be the case
17:19:28Sentreenmratsim: use the --project switch
17:19:36*cspar_ joined #nim
17:21:24FromGitter<mratsim> @Sentreen: It doesn’t work. I suppose it’s generating doc for import but not for include
17:21:27*yglukhov joined #nim
17:21:51Vi-subsetpark, seems like type inference doesnt work on generic types? At least not in that context
17:21:52*gmpreussner quit (Read error: Connection reset by peer)
17:22:05*cspar quit (Ping timeout: 240 seconds)
17:22:11subsetparkYeah, but the proc I just tried it with was concrete
17:22:24Vi-mhm I tried that too I think
17:22:38Vi-I have a table
17:22:48Vi-It does compile but I cant specify the type
17:23:08Vi-I kinda wanted to do that to prevent adding random functions to it and erroring out that way but oh well
17:23:27*nhywyll joined #nim
17:24:11SentreenAh sorry, I thought you said import
17:25:12*gmpreussner joined #nim
17:37:28*Trustable quit (Remote host closed the connection)
18:04:23Vi-Got another error
18:04:26Vi-process_assets.nim(68, 1) Error: request to generate code for .compileTime proc: traverse
18:04:36Vi-traverse is definitely not .compileTime
18:04:48FromGitter<TiberiumN> what can I use to pass data like this: ⏎ ⏎ ```let data = {"a": "asdasd", "b": "bar"}``` ⏎ ⏎ to procedures? [https://gitter.im/nim-lang/Nim?at=595fcd4089aea4761d7661d4]
18:05:36Vi-afaik thats a set of tuples
18:05:45Vi-Id use tables
18:05:59*pilne joined #nim
18:06:03Vi-but yea
18:06:05Vi-https://github.com/Victorious3/CGMPT/blob/master/src/process_assets.nim#L50
18:06:07FromGitter<TiberiumN> I want to somehow avoid using "toTable" everythere
18:06:21Vi-This doesnt have .compileTime at all
18:07:05*bit_lySLH2uSZHed joined #nim
18:08:25*bit_lySLH2uSZHed left #nim (#nim)
18:10:22Araqtierium: proc takeSuff(x: openArray[(string, string)]) = ...
18:10:28AraqtakeSuff(data)
18:11:41AraqVi-: it is compiletime
18:11:47Vi-Why?
18:11:50AraqResource has ast: NimNode
18:12:07Araqwith means everything dealing with Resource is implicitly .compileTime
18:12:19Vi-Well I wanted to use asts for some code generation
18:12:27Vi-this is a workaround because theres no compile time ffi
18:12:50Vi-I just want to generate some code with it not run anything at compile time
18:12:58Araqwell code generation is compiletime
18:13:06Vi-source code
18:13:07Vi-text
18:14:00Vi-this is supposed to turn into a script that reads the asset folder and then generates a source file called "resources.nim" which has all the information about shaders, etc
18:14:25Araqthe compiler is correct, you need to write this in some different way
18:14:35Vi-Yes, but how?
18:14:36Araqbut I don't really understand what you're trying to do, sorry.
18:14:44Vi-Araq, well...
18:15:01Araqyou can import the compiler as a library into your program, perhaps?
18:15:02Vi-shaders, I want to figure out the uniform names
18:15:16Vi-And the only way to do that is to run opengl
18:15:28Vi-and I obviously cant do that at compile time
18:15:41Araqyeah, but you can import the Nim compiler :-)
18:15:49Vi-And how does that help me?
18:17:44FromGitter<ephja> this seems complicated
18:18:06*Trustable joined #nim
18:18:22Vi-Well if it ends up working itd be super useful
18:18:42Vi-having code completion for shaders without having to do anything
18:20:32Vi-Araq, so I import the compiler, and then?
18:20:55FromGitter<ephja> but you would have to create a context at run time as well. are the locations deterministic?
18:21:11Vi-ephja, not the locations but the names
18:21:31Vi-I just need to run opengl to parse the shader file
18:22:00Vi-Involves a bit of hackery like spawning an invisible window, etc... but in theory...
18:22:08Vi-if I manage to get this sorted out that is
18:22:15*Trustable quit (Remote host closed the connection)
18:24:58AraqVi-: use a helper Nim program to produce the names, write them out, read them in at compiletime in the real Nim program?
18:25:09Vi-thats what Im trying to do
18:25:29Vi-I wanted to use the ast to help me with the code generation
18:25:40Vi-with repr
18:26:14Araqwrap the proc calls into a 'static' block perhaps?
18:26:22Vi-I could create another one which only does the shaders and then somehow passes that information but it becomes increasingly crazy
18:26:35Vi-Araq, then I run into the same problem with not being able to call anything opengl
18:28:16Vi-I mean
18:28:22Vi-I could do a lot of string concat
18:28:33Vi-but that becomes ugly really fast
18:29:20FromGitter<ephja> in what context will you be querying this metadata?
18:29:54Vi-main program
18:29:59Vi-so that I can do things like...
18:30:24Vi-resources.shader.frag.core.myUniform = vec2(...)
18:30:41Vi-without having to specifiy anything anywhere, just reading from the folder structure
18:30:42*tankfeeder joined #nim
18:31:02Vi-because all the information is already present at compile time, I just have to use it...
18:32:06*tankfeeder_ joined #nim
18:33:20Vi-Wanted to do this since forever and was all excited about nims compile time code evaluation but then... no compile time ffi :/
18:33:42FromGitter<ephja> I'm trying to figure out why the same level of convenience can't be achieved with runtime querying
18:33:47Vi-I could do some hackery to get around that I think but it doesnt seem right
18:33:57Vi-@ephja, code completion
18:33:59Vi-editor
18:34:10Vi-and having everything checked at compile time
18:34:31AraqI don't understand why you need to keep the NimNode in the resource and not the 'string' (= repr ast)
18:34:43FromGitter<ephja> right
18:34:46Vi-Araq, sure I can do that
18:34:48Araqyou can parseExpr() the string back into an AST later
18:34:51FromGitter<ephja> that's one benefit of having a DSL
18:34:56Vi-but at some point I'll have to call a function that uses an ast
18:35:11*yglukhov quit (Remote host closed the connection)
18:35:15Vi-readProg <- is supposed to do that
18:35:18*chrisheller joined #nim
18:39:09FromGitter<ephja> well, or a shader API. I hope vulkan is more flexible in this regard. I assume it is
18:39:32Vi-I somehow assumed that using "macro" was the problem and didnt know that simply using a NimNode turns everything into compile time
18:40:01Vi-ephja, well, doesnt spare me from having to run C functions at compile time ^^"
18:40:56Vi-but then again, if it worked that way then I didnt have to use an external program... Duh. This is inconvenient
18:40:58*tankfeeder_ quit (Remote host closed the connection)
18:41:15*tankfeeder_ joined #nim
18:41:18Vi-Araq, there any specific reason why compile time ffi isnt allowed?
18:41:21Vi-Or is it just not implemented yet?
18:42:49AraqI implemented it twice
18:43:04Araqit's just not something I'll ever get stable
18:43:36Vi-I'm not sure about the details but whats required for it?
18:43:51*tankfeeder_ quit (Client Quit)
18:44:18*yglukhov joined #nim
18:44:29Vi-It sounds like something interesting to tackle
18:45:32Vi-but uh, either ways, I need to somehow create an ast at runtime and repr it
18:47:08Vi-Or I do something else like... creating an intermediate format and then using the main program to parse that again but its more work
18:47:24Vi-or string concatination for everything but neither sounds nice
18:48:04Vi-compile time ffi would fix it...
18:49:49krux02Vi: the VM of nim works a bit different than you might think
18:50:18krux02on the nimvm all types are reference types, but they try to emulate the same semantic as the flat C types
18:50:19Vi-I dont know how it works and I'm not making any guesses either
18:50:38Vi-having ffi at compile time does sound *possible* to me
18:50:46krux02therefore you cannot pass pointers from nimvm types to a c function
18:50:53krux02the memory layout is simply very different
18:51:04Vi-well then I only use c types?
18:51:12krux02no not even then
18:51:29Vi-I have the dll
18:51:34krux02when you execute a function at compile time it is compiled to bytecode
18:51:45krux02and those types the nimvm uses are not C types
18:51:46Vi-I could hack my way into calling the functions manually
18:51:53krux02they behave like them, but they are not
18:52:36krux02well i am sure that a limited ffi would work, but general C wrappers of C libraries don't
18:52:59Vi-or I could use some other program thats not written in C to achieve the same and then feed the information to nim via that detour
18:53:18krux02well you call call any program from nim
18:53:20Vi-s/not//
18:53:22krux02that is not a problem
18:53:29*nsf joined #nim
18:53:37Vi-yes but its a terrible workaround
18:53:58Vi-One of the kind that makes me rip my hair out
18:53:59krux02Well, nim is not jai
18:54:13Vi-I guess
18:54:18krux02but hey much better than C++ ;)
18:54:19Vi-but why cant it do what jai does?
18:54:25Vi-since...
18:54:37*Trustable joined #nim
18:54:38Vi-this syntax with jais features would be the absolute killer language
18:54:42Vi-Id never have to use anything else
18:54:54krux02well I did not design nim and I was very surprised when I saw how the nimvm was implemented
18:55:03krux02it is something that I would have wanted to know earlier
18:55:20krux02because it is also me who assumed and really wanted a c ffi at some point in time
18:55:30Vi-I came into it with the assumption that you could run any code at compile time you wanted
18:55:40krux02I just got that things that I thought I needed done without the ffi
18:55:43Vi-since everything suggests that
18:55:56shashlickAraq: when do issues typically get marked as closed? After PR is pulled in or on next official release?
18:56:01krux02yea it is not any code
18:56:12Araqshashlick: when it's fixed in devel
18:56:13krux02it is a subset of the nim language
18:56:16Vi-Oh yea I could write a parser for glsl in... nim... but then I'm not done in the next year
18:56:22AraqVi-: koch boot -d:release -d:useFFI
18:56:36krux02Araq: interesting
18:56:36Araqthe feature is still there
18:56:42Vi-What does that do?
18:56:46Araqyou probably need to make it compile again
18:56:48Vi-And how do I use it?
18:56:55AraqVi-: it enables FFI at compiletime
18:56:59krux02Vi koch is the build tool for the compiler
18:57:10krux02basically the build script for the compiler
18:57:11shashlickAraq: okay, then do I need to chase down someone to close it or just wait for one of the contributors to get around to it?
18:57:14Vi-So I need to compile the compiler with that switch?
18:57:33Araqshashlick: link? I can close it for you
18:57:46AraqVi-: yes
18:58:00Vi-Like if I knew that compile time ffi was planned for the future then Id just postpone this whole asset thing until much later
18:58:16krux02Vi-: what are you working on, you said something with glsl
18:58:48Vi-Was just an experiment but I feel like it could turn into something useful
18:59:04Vi-city generator, some rendering in opengl
18:59:11krux02ah, ok
18:59:20krux02any specific reason to use Nim?
18:59:24koppehEssentially, pre-processing assets so you have auto-completion and error checking on stuff like shaders for example.
18:59:36Vi-krux02, because its awesome
18:59:50koppehprogram.someuniform = foo
19:00:13krux02well I have a project like that already written in Nim
19:00:50Vi-mh, afk for a while
19:00:51*arnetheduck joined #nim
19:00:53krux02it doesn't work an a mac
19:01:00Vi-Araq, I'll try that for curiosity
19:01:05krux02but it does that program.someuniform = foo think
19:01:26Vi-krux02, checking at runtime, then?
19:01:41Vi-mh, afk
19:01:47krux02and when you do that it even generates the code in glsl so that you can use someuniform in the shader with the type of foo
19:02:22krux02Vi, no I don't check at runtime, I do it the other way around, I use the types system from Nim and generate the glsl part
19:02:35krux02turned out to be much nicer
19:03:36krux02I even made a video describing it, but I hate my slow speaking: https://www.youtube.com/watch?v=JO0iqGDgFqA&t=862s
19:03:53krux02my first time recording something for youtube
19:04:15krux02at least youtube has a 1.5 times speed option and my video is a candidate for it
19:05:13krux02here is the hello triangle code: https://github.com/krux02/opengl-sandbox/blob/master/examples/hello_triangle.nim
19:06:56*Vi- quit (Ping timeout: 260 seconds)
19:08:16krux02koppeh: are you in the same project with Vi-
19:08:18krux02?
19:08:24koppehYeah.
19:08:25shashlickAraq: https://github.com/nim-lang/Nim/issues/5736, https://github.com/nim-lang/Nim/issues/6044
19:08:36*dddddd joined #nim
19:09:06krux02what you plan to do sounds very similar to what I wanted to do initially, too. But then it evolved ito what I currently have
19:09:47krux02so I would really like to have some feedback on that project, and I would like to see what you are working on, of there is something like a github page
19:11:04koppehThe resources thing was more Vi's idea.
19:11:54Araqshashlick: "Manjaro doesn't work either." still an issue?
19:11:57koppehI was kinda against it because we're supposed to be in prototyping stage.
19:12:10koppehhttps://github.com/Victorious3/CGMPT
19:12:25koppehI suppose it doesn't hurt to share but there's basically nothing.
19:17:37krux02since you already wrap poll event you could provide an iterator interface for that
19:18:49*Matthias247 joined #nim
19:19:09koppehTrue, lemme see the nim manual ^^
19:21:29krux02basically you but the polling in the iterator, and then when you use it you simply use a for loop
19:23:43*tankfeeder quit (Quit: Leaving)
19:25:28shashlickWhat's manjaro
19:27:34koppehshashlick: A distro based on Arch (https://manjaro.org/)
19:28:40shashlickI haven't tried it, is there another issue for that
19:29:57krux02is there an easy way to pass a seq as varargs?
19:33:29koppehkrux02: Can't you do that by default?
19:34:09koppehJust.. pass the seq as the argument?
19:43:24*murych joined #nim
19:43:49*Vi- joined #nim
19:44:35Vi-krux02, yea then no autocomplete and you can pick the wrong type. Uh, should really configure my bouncer for this
19:45:11Vi-Im thinking I'll just generate the metadata with a script and put it into some simple file format and then parse that from main
19:50:07krux02koppeh: yea I figured that out, I thought there was something fancy, because in Scala I remember to write some weird :_* stuff for that
19:50:13krux02then I never used varargs
19:51:50krux02Vi-: yes you can do that
19:52:26Vi-I assume I can read files at compile time?
19:53:02krux02Vi-: you are right I don't have autocomplete in glsl because it is just a string in Nim, but that is not really a problem to me.
19:53:07krux02yes you can
19:53:10krux02slurp
19:53:13Vi-good, good
19:53:21Vi-krux02, well its second next best thing to it ^^
19:53:48krux02you call call a script and get the output as a string
19:54:17Vi-Give me a language like that and I'll try to break every rule possible :3
19:54:19krux02and that feature has some caching argument, so that the script is only executed when there is acutally a different cache argument
19:54:24Vi-what I did for glew wasnt exactly clean either
19:54:47Vi-newStrLitNode("__imp___GLEW_" & $extension) <-
19:55:09Vi-krux02, yup
19:55:09krux02newLit("...") does also work
19:55:47krux02any reason to use glew instead of the opengl binding?
19:56:16Vi-so that I dont have a hard dependency on all functions Im using
19:56:37krux02sorry you use opengl
19:56:37Vi-With that macro I can do... if glewGetVar(KHR_debug): ...
19:56:54Vi-yea I use opengl just with glew behind it
19:57:40krux02yea that is a problem in the opengl thing
19:57:43Vi-getting it to work that way was quite... challenging
19:57:57krux02all function it finds in the program are required or it won't start
19:58:18krux02would be nice, if you could contribute back somehow to the opengl package
19:58:29Vi-I fould -d: useGlew
19:58:42Vi-Its just that I have to call some of the glew functions directly to get it to work
19:58:44krux02ah, ok
19:58:45Vi-*found
19:59:34Vi-maybe I could work on something that doesnt use glew but allows to have some optional stuff but I'm not sure how
19:59:53Vi-but yea I found a workaround
20:05:30*Trioxin quit (Quit: Konversation terminated!)
20:16:49krux02ok I go offline now, bye
20:17:24*krux02 quit (Remote host closed the connection)
20:24:16*rokups quit (Quit: Connection closed for inactivity)
20:26:30yglukhovAraq: which command should i send to nimsuggest to get module path, when tocken in question is module name.
20:26:58Araqdef?
20:27:39yglukhovdoesn't work :(
20:27:46yglukhovbut it should, right?
20:29:08Araqright
20:35:51*nhywyll quit (Quit: nhywyll)
20:36:29yglukhovAraq: does this look like a reason why it doesn't work? https://github.com/nim-lang/Nim/blob/devel/compiler/importer.nim#L188
20:36:51yglukhov=)
20:37:10Araqyes
20:38:20yglukhovso. lets see.. why cant i uncomment this... oh right.. nim doesn't support cyclic imports :P
20:43:36yglukhovAraq: can your benign kungfu or smth help here?
20:44:04Araqjust do it later in semstmts.nim then
20:47:12Araqgood night
20:58:54yglukhovgood night
21:18:35*rauss joined #nim
21:18:36*rauss quit (Client Quit)
21:18:51*user200112 joined #nim
21:30:22*krux02 joined #nim
21:33:52*xet7 quit (Quit: Leaving)
21:37:16*shashlick quit (Quit: Connection closed for inactivity)
21:45:31*Trustable quit (Remote host closed the connection)
21:54:36*salewski quit (Quit: WeeChat 1.4)
22:31:48*shashlick joined #nim
22:34:53*couven92 quit (Quit: Client Disconnecting)
22:51:07*user200112 quit (Quit: Leaving)
22:56:10*smt quit (Changing host)
22:56:10*smt joined #nim
23:15:07*nsf quit (Quit: WeeChat 1.7.1)
23:43:42*murych quit (Ping timeout: 240 seconds)
23:45:13*Nobabs27 joined #nim
23:47:53*Nobabs25 joined #nim
23:49:29*Nobabs227 joined #nim
23:50:51*Nobabs27 quit (Ping timeout: 268 seconds)
23:52:42*Nobabs25 quit (Ping timeout: 268 seconds)
23:54:42*Nobabs227 quit (Ping timeout: 240 seconds)
23:54:57*Nobabs227 joined #nim