| 00:08:57 | * | cspar joined #nim |
| 00:11:15 | * | cspar_ quit (Ping timeout: 252 seconds) |
| 00:13:11 | * | leorize quit (Quit: WeeChat 2.3) |
| 00:17:55 | * | Notkea quit (Read error: Connection reset by peer) |
| 00:18:18 | * | Notkea joined #nim |
| 00:18:41 | * | wildlander quit (Quit: Konversation terminated!) |
| 00:44:31 | * | stefanos82 quit (Remote host closed the connection) |
| 00:46:19 | * | shpx joined #nim |
| 00:52:08 | * | rayman22201 joined #nim |
| 01:04:38 | * | seni quit (Quit: Leaving) |
| 01:04:53 | * | lritter quit (Quit: Leaving) |
| 01:18:05 | * | Vladar quit (Remote host closed the connection) |
| 01:34:20 | * | Ven`` joined #nim |
| 01:37:07 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 02:02:56 | * | Tyresc quit (Quit: WeeChat 2.4-dev) |
| 02:23:53 | * | Ven`` quit (Ping timeout: 246 seconds) |
| 02:28:15 | * | dddddd quit (Remote host closed the connection) |
| 02:46:43 | * | PrimHelios joined #nim |
| 02:46:43 | * | PrimHelios quit (Remote host closed the connection) |
| 02:57:00 | * | abm quit (Ping timeout: 258 seconds) |
| 02:57:00 | * | zyklon quit (Read error: Connection reset by peer) |
| 03:00:35 | * | banc quit (Quit: Bye) |
| 03:00:49 | * | Snircle quit (Read error: Connection reset by peer) |
| 03:01:46 | * | Snircle joined #nim |
| 03:13:58 | * | zyklon joined #nim |
| 03:18:19 | * | banc joined #nim |
| 03:27:57 | * | zachk quit (Quit: Leaving) |
| 03:56:04 | * | abm joined #nim |
| 04:11:40 | * | d10n-work joined #nim |
| 04:26:48 | * | nsf joined #nim |
| 05:11:00 | * | d10n-work quit (Ping timeout: 252 seconds) |
| 05:13:20 | * | d10n-work joined #nim |
| 05:19:01 | * | shpx quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:29:53 | FromDiscord_ | <Geroro / Grey Ghost> Hi all! I just loaded up SDL2 without problems but my program can't find SDL2_Image, I've included both in the same directory and after an hour of debugging am completely lost |
| 05:38:44 | shashlick | Please post a snippet |
| 05:38:44 | * | zyklon quit (Read error: Connection reset by peer) |
| 05:42:47 | * | BigEpsilon joined #nim |
| 05:56:08 | * | zyklon joined #nim |
| 06:05:18 | * | leorize joined #nim |
| 06:11:30 | * | narimiran joined #nim |
| 06:18:34 | * | narimiran quit (Quit: Leaving) |
| 06:18:53 | * | narimiran joined #nim |
| 06:37:04 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 06:43:56 | * | BigEpsilon quit (Ping timeout: 246 seconds) |
| 07:12:18 | * | krux02 joined #nim |
| 07:23:54 | * | sheerluck joined #nim |
| 07:29:24 | * | Notkea quit (Remote host closed the connection) |
| 07:31:38 | * | BigEpsilon joined #nim |
| 07:45:42 | * | mbomba joined #nim |
| 07:46:49 | * | mbomba left #nim (#nim) |
| 07:49:58 | * | xace quit (Read error: Connection reset by peer) |
| 07:51:37 | * | xace joined #nim |
| 07:54:49 | * | Vladar joined #nim |
| 08:33:08 | * | avsej quit (Ping timeout: 250 seconds) |
| 08:33:09 | * | avsej_ joined #nim |
| 08:33:09 | * | avsej_ quit (Changing host) |
| 08:33:09 | * | avsej_ joined #nim |
| 08:33:32 | * | avsej_ is now known as avsej |
| 08:34:36 | * | Gertm joined #nim |
| 08:42:26 | * | vlad1777d_ joined #nim |
| 08:43:09 | * | vlad1777d quit (Ping timeout: 258 seconds) |
| 09:04:07 | FromDiscord_ | <Valgrind> Morning! What does `static x` (instead of say `var x`) mean? |
| 09:04:39 | leorize | !eval static x = 0 |
| 09:04:39 | NimBot | Compile failed: <no output> |
| 09:05:28 | leorize | @Valgrind: are you talking about something like this `proc a(b: static int)`? |
| 09:07:34 | FromDiscord_ | <Valgrind> Yes. |
| 09:07:44 | leorize | here you go: https://nim-lang.org/docs/manual.html#special-types-static-t |
| 09:08:06 | FromDiscord_ | <Valgrind> Oh thanks. |
| 09:10:58 | * | Gertm left #nim ("Leaving") |
| 09:56:53 | * | vlad1777d_ quit (Ping timeout: 268 seconds) |
| 09:57:33 | * | vlad1777d_ joined #nim |
| 10:03:06 | * | dom96_w joined #nim |
| 10:11:50 | FromGitter | <mratsim> static means compile-time evaluation |
| 10:39:44 | * | hoijui joined #nim |
| 10:45:48 | * | PMunch joined #nim |
| 10:54:40 | * | floppydh joined #nim |
| 11:22:04 | * | rect0x51 joined #nim |
| 11:30:00 | * | vlad1777d_ quit (Ping timeout: 268 seconds) |
| 11:31:06 | * | vlad1777d_ joined #nim |
| 11:31:07 | * | rect0x51 quit (Quit: WeeChat 2.3) |
| 11:57:46 | * | cspar_ joined #nim |
| 11:59:43 | Zevv | Is there a specific philosophy in Nim design considering modifying/deleting lists/seqs/tables while iterating? When is this considered safe/unsafe? |
| 12:00:34 | * | cspar quit (Ping timeout: 258 seconds) |
| 12:00:44 | * | theelous3 joined #nim |
| 12:06:11 | Araq | yes. don't |
| 12:07:06 | narimiran | :D |
| 12:15:15 | * | seni joined #nim |
| 12:15:24 | * | seni left #nim (#nim) |
| 12:17:10 | Zevv | that's pretty clear |
| 12:17:58 | * | stefanos82 joined #nim |
| 12:18:27 | * | dddddd joined #nim |
| 12:21:00 | FromGitter | <alehander42> well you can modify an element |
| 12:23:03 | Zevv | True, the list doesn't care about the elements. But adding elements while iterating is not ok, just as deletion |
| 12:23:21 | Zevv | Is this mentioned in the docs somewhere? |
| 12:24:11 | narimiran | it is "well known" |
| 12:25:29 | FromGitter | <zacharycarter> is there a programming language where this is encouraged? |
| 12:25:44 | FromGitter | <zacharycarter> not trying to be a dick - genuinely curious |
| 12:26:44 | Araq | system.nim has an assertion to cover that |
| 12:27:02 | Araq | for seqs and so in theory Tables also have this check |
| 12:27:17 | Araq | since they are based on seqs. I never tried it though, let's see |
| 12:28:08 | Zevv | Lua allows deletions: "The behavior of next is undefined if, during the traversal, you assign any value to a non-existent field in the table. You may however modify existing fields. In particular, you may clear existing fields." |
| 12:28:49 | Zevv | Araq: table's pairs() does not complain |
| 12:28:55 | Araq | I noticed, that's bad |
| 12:48:13 | * | dorelix quit (Remote host closed the connection) |
| 12:50:50 | * | dorelix joined #nim |
| 12:59:03 | * | BigEpsilon quit (Ping timeout: 252 seconds) |
| 12:59:21 | * | BigEpsilon joined #nim |
| 12:59:55 | FromGitter | <mratsim> Python complains |
| 13:08:01 | FromGitter | <timotheecour> @araq is there a way to get RTTI in Nim? eg use case: nim-based lld (or gdb, doesn’t matter) helpers such as formatters, so I could simply run: ⏎ `(lldb) $ myvar` and have custom logic in nim to traverse `myvar` (eg print fields that i want etc) |
| 13:09:03 | FromGitter | <timotheecour> I know how to do it at CT, but I need to do it at RT since the queries are known at RT (say, during a lldb debug session) |
| 13:10:32 | FromGitter | <timotheecour> I don’t mind if it requires an extra flag that slows down performance a bit, it’s for debugging ; (also note that that could also be also useful for REPL applications) |
| 13:15:11 | FromGitter | <timotheecour> note that lldb API provides this (eg: https://lldb.llvm.org/python_reference/lldb.SBModule-class.html) but it’d require interop wrappers bw python and nim which is a pain (and would also have the cgen artifacts), so i was wondering if there’s a direct way, say, given a pointer to a variable + a type name |
| 13:18:31 | FromGitter | <alehander42> @timotheecour why don't you want to use python pretty printers? this is working well for gdb and I suppose it would well for lldb as well |
| 13:20:32 | FromGitter | <timotheecour> several reason: first, gdb hasn’t been supported on OSX since latest OSX (mojave) (see my other reported issues on this; there may be hope coming but still, lldb is more feature-rich) |
| 13:20:41 | * | BigEpsilon quit (Ping timeout: 258 seconds) |
| 13:20:57 | * | BigEpsilon joined #nim |
| 13:21:20 | FromGitter | <alehander42> ok, but doesn't lldb also have support for python scripting |
| 13:21:48 | FromGitter | <timotheecour> 2nd, i did try (with patched gdb to overcome above limitations) but getting missing debug info eg: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ as well as `b foo` not working (whereas it works on lldb) [https://gitter.im/nim-lang/Nim?at=5c34a3ec82a6c30b90a3ba0f] |
| 13:22:30 | FromGitter | <alehander42> wait, what do you mean by "gdb is not working on osx" |
| 13:22:42 | FromGitter | <alehander42> gdb itself? even for c/c++ programs? |
| 13:22:47 | FromGitter | <alehander42> this can't be true |
| 13:23:01 | FromGitter | <timotheecour> third (but maybe consequence of above), with the `tools/nim-gdb.py` I’m getting errors of the form: ⏎ ⏎ ```configVars = , Python Exception <class 'gdb.error'> There is no member named Sup.:``` [https://gitter.im/nim-lang/Nim?at=5c34a4354ed18278777a50cf] |
| 13:24:04 | FromGitter | <alehander42> I've written a good amount of various python commands for gdb last year and they seemed to work well with the nim debug info |
| 13:24:49 | FromGitter | <alehander42> hm, well this might be just a bug in nim-gdb.py, you should report it with reproducable example |
| 13:24:51 | FromGitter | <timotheecour> Sadly this is true, see https://stackoverflow.com/questions/49001329/gdb-doesnt-work-on-macos-high-sierra-10-13-3 |
| 13:25:38 | FromGitter | <timotheecour> the fixes mentioned don’t work on latest OSX (mojave); (and even `brew` version of gdb doesn’t work; i’ve been following this closely and reporting bugs upstream since a year) |
| 13:26:03 | FromGitter | <alehander42> huh, very strange |
| 13:26:28 | FromGitter | <timotheecour> it’s a well known problem. gdb is just not tested on OSX. |
| 13:28:58 | FromGitter | <timotheecour> that being said, lldb is IMO the way forward, receiving much more development and features compared to gdb, and yes, to answer your quesiton there’s extensive python scripting available, I can do basic traversal of nim strucutres in lldb in python already |
| 13:30:26 | FromGitter | <timotheecour> but having some RTTI to do it in nim would have a lot of benefits for debugging (and REPL etc) |
| 13:30:49 | FromGitter | <alehander42> I've written commands that can traverse all kinds of nim values based on runtime info: the only limitation i had is that enum/case object info should be always emitted for all types in debug mode |
| 13:31:45 | FromGitter | <alehander42> @timotheecour what do you call 'rtti' exactly? rtti is additional data, but I feel like you're talking about additional functions? if it's data, what data do you think is missing? |
| 13:32:06 | FromGitter | <timotheecour> so how would that work given a pointer (just an address) and a type (eg `tyObject_TSym_JpsEh5i1AcKChGYbg7aV4w`) ? |
| 13:32:39 | FromGitter | <alehander42> well, you can analyze the type using the scripting api? |
| 13:32:51 | FromGitter | <alehander42> (at least in gdb this is easy to do) |
| 13:33:20 | FromGitter | <timotheecour> RTTI : run time type information; basically at CT it’s relatively easy to do traversal and it can be made to work with anything (seq, map etc); but not sure how to do it at RT where types are not known |
| 13:33:41 | FromGitter | <alehander42> wait, I see |
| 13:33:44 | FromGitter | <alehander42> so in gdb basically |
| 13:33:48 | FromGitter | <alehander42> you can traverse the types |
| 13:33:54 | FromGitter | <alehander42> it has this builtin |
| 13:33:59 | FromGitter | <alehander42> in the command API-s |
| 13:34:07 | FromGitter | <alehander42> is this not possible in lldb? |
| 13:34:33 | FromGitter | <alehander42> (basically the types are known, because they are in the debug info, e.g. dwarf etc) |
| 13:35:04 | FromGitter | <timotheecour> one problem is after c-gen I’m loosing the original nim struture, eg for generics, `Foo[int]` => no way to get `Foo` nor `int` param at RT from debug info, is there |
| 13:36:01 | * | theelous3 quit (Ping timeout: 258 seconds) |
| 13:36:11 | FromGitter | <timotheecour> yes, lldb can traverse types, but it’s the cgen types, we loose the original structured type (eg AST) |
| 13:36:32 | FromGitter | <mratsim> maybe with the typeinfo module? https://nim-lang.org/docs/typeinfo.html |
| 13:39:00 | FromGitter | <alehander42> @timotheecour yeah, but the cgen types are pretty important to be able to actually traverse the runtime value correctly |
| 13:39:00 | FromGitter | <timotheecour> I’m thinking of a compiler flag that could go over all known types and register a callback `print(p: pointer, typename: string)` that could then be used for all types given their name (which lldb knows); and that `printNim` could be itself implementd using an auxiliary proc that can traverse at CT |
| 13:39:09 | FromGitter | <alehander42> otherwise the generic thing is a good point |
| 13:39:48 | FromGitter | <alehander42> i think there was a sighashes flag which had some ability to serialize sighash => nim type |
| 13:39:51 | FromGitter | <alehander42> or something like that |
| 13:40:53 | FromGitter | <alehander42> btw @timotheecour you know, that you can also call dollar__<yourtype> right |
| 13:41:03 | FromGitter | <timotheecour> @mratsim oh ya. had forgotten about https://nim-lang.org/docs/typeinfo.html ; how would i use it given pointer + mangled typename ? |
| 13:41:20 | FromGitter | <alehander42> i've also done this before |
| 13:41:25 | FromGitter | <mratsim> I have no idea, I never used it but apparently that’s the way to do RTTI :P |
| 13:41:33 | FromGitter | <alehander42> basically you traverse all the dollar__ functions in your lldb script |
| 13:41:41 | FromGitter | <alehander42> and map them to types based on their arg type |
| 13:41:57 | FromGitter | <alehander42> and later you know which one you need to call for each value |
| 13:42:04 | FromGitter | <timotheecour> `dollar__<yourtype> ` would only work for `<yourtype>` that I implement though, right? |
| 13:42:18 | Araq | why is Foo[int] important? it's debugging, you get all the struct values |
| 13:42:41 | FromGitter | <alehander42> well yeah, but on the other hand this will let you `echo` while you're debugging: just another thing that might be useful for someone |
| 13:43:23 | FromGitter | <timotheecour> `Foo[int]` is important as it allows me to dispatch to appropriate printing proc (eg seq vs map vs my_custom_type_with_custom_print) |
| 13:44:40 | FromGitter | <timotheecour> by the time it’s a mangled name, all i get is low-level C fields ; i want flexibility of printing the way i’d do it nim `proc myprintT (a:T)` which can do anything |
| 13:45:04 | FromGitter | <alehander42> but it's very easy to demangle the fields and to get the higher level nim view of them |
| 13:45:21 | FromGitter | <alehander42> @timotheecour so why not just using `$` |
| 13:45:32 | FromGitter | <alehander42> it already works and people already implement it for their custom types |
| 13:45:46 | FromGitter | <alehander42> and you can have a universal repr as a backup |
| 13:45:57 | * | rect0x51 joined #nim |
| 13:46:40 | rect0x51 | Hey guys, I am struggling to understand Concepts, what should I do other than reading the Manual? |
| 13:46:42 | FromGitter | <timotheecour> can u use nim's `$` in a debugger (gdb or lldb, whatver) on arbitrary variable? how could that work? |
| 13:47:01 | FromGitter | <alehander42> @timotheecour ⏎ ⏎ > @alehander42 ⏎ basically you traverse all the dollar__ functions in your lldb script ⏎ and map them to types based on their arg type ... [https://gitter.im/nim-lang/Nim?at=5c34a9d582a6c30b90a3e9ff] |
| 13:47:33 | FromGitter | <alehander42> at least that's what I did in gdb |
| 13:47:48 | * | theelous3 joined #nim |
| 13:47:56 | Araq | rect0x51, avoid them. ;-) |
| 13:48:14 | rect0x51 | Araq: No! I like the concept of concepts |
| 13:48:23 | Araq | it's a fancy way to write generic parameter constraints, it's not an interface |
| 13:48:53 | rect0x51 | Is there an interface feature like in Java, for Nim? |
| 13:48:58 | Araq | and parameter constraints hardly enable anything as the generic parameters are usually "lazily" checked |
| 13:49:01 | FromGitter | <alehander42> @rect0x51 well it's not hard to use it as an interface: you just need to list proc statements |
| 13:49:14 | Araq | no! |
| 13:49:26 | Araq | concepts are not interfaces and there is an eternal confusion about them. |
| 13:49:50 | FromGitter | <timotheecour> concepts = duck typing |
| 13:49:58 | Araq | with an interface I can do seq[SomeInterface] and get a heterogenous collection |
| 13:50:07 | Araq | with a concept I don't get that. |
| 13:50:52 | FromGitter | <alehander42> well yeah, i mean you can use them to immitate interface args, I agree it doesn't work for returning |
| 13:51:04 | Araq | the Nim way of doing interfaces is to use first class procs or tuples of these |
| 13:51:46 | rect0x51 | I need practice... |
| 13:52:49 | * | craigger_ joined #nim |
| 13:53:16 | rect0x51 | Araq, I think I read something about Nim getting interfaces |
| 13:53:25 | Araq | https://github.com/nim-lang/Nim/blob/devel/tests/closure/tclosure.nim#L70 |
| 13:53:31 | rect0x51 | Are there such thoughts floating around? |
| 13:54:17 | Araq | there are macros to give you these, I don't want to add them to the language directly |
| 13:54:40 | * | craigger quit (Ping timeout: 250 seconds) |
| 13:55:13 | Araq | I programmed in C# quite a bit, Nim is better without 'interface'. |
| 13:56:23 | rect0x51 | Yeah well, interface is nothing special, Nim's macros should cover it just find. Have to run... thanks for the advice, I'll try to find some project so I can practice macros and generics. |
| 13:56:32 | rect0x51 | just fine* |
| 13:56:59 | rect0x51 | bye~ |
| 13:57:05 | FromGitter | <timotheecour> @alehander42 were u one of the authors of tools/nim-gdb.py ? i’m seeing it point to krux and coldome; looking at `DollarPrintFunction` it requires `$` to be instantiated in the binary otherwise the symbol won’t be available right? so if ur binary never calls `$(Foo[float])` but u wanna `echo` a variable who has a `Foo[float]` field, how can it work? |
| 13:57:13 | * | rect0x51 quit (Quit: WeeChat 2.3) |
| 13:57:58 | * | pwntus quit (Ping timeout: 245 seconds) |
| 14:00:23 | * | BigEpsilon quit (Ping timeout: 268 seconds) |
| 14:00:41 | * | BigEpsilon joined #nim |
| 14:03:01 | * | pwntus joined #nim |
| 14:04:42 | * | hoijui quit (Ping timeout: 268 seconds) |
| 14:20:15 | FromGitter | <timotheecour> hah, so all i’d need is a way to get `rawTypePtr` from a variable in lldb; with it i could build a typeinfo.Any, and then I’d be in business |
| 14:21:07 | FromGitter | <timotheecour> (eg traversing fields at RT, dispatching etc) |
| 14:26:12 | FromGitter | <alehander42> @timotheecour no, they wrote it, I have my own equivalent set of python commands, that's what i based my comments on |
| 14:27:10 | FromGitter | <alehander42> @timotheecour well, I suppose that one can instantiate `$` for each materialized type in debug mode |
| 14:27:17 | FromGitter | <alehander42> this would make sense |
| 14:29:35 | FromGitter | <timotheecour> but i’m thinking a more generic approach is based on `typeinfo` ; all i need is a way to get the typePtr from lldb , and then we have all we need for arbitrary RT traversal or mutation; there shd be a way since lldb (or gdb, distinciton irrelevant here) already knows how to get type name and traverse it too |
| 14:33:17 | * | hoijui joined #nim |
| 14:33:58 | FromGitter | <alehander42> well, you need a map between cgenned typenames and type ptrs? |
| 14:35:12 | FromGitter | <timotheecour> Ya |
| 14:35:58 | FromGitter | <timotheecour> so i guess i’d need to patch the compiler to output that right? (analog to the .ndi files that print mangled/unmangled pairs) |
| 14:36:37 | FromGitter | <timotheecour> unless that type pointer is somewhat accessible from a debugger? do u think that’s the case? |
| 15:02:16 | * | kapil____ joined #nim |
| 15:04:23 | * | rokups joined #nim |
| 15:14:36 | krux02 | timotheecour: you want to use the nim-gdb integration? |
| 15:15:35 | krux02 | the good news is, you can call arbitrary nim functions from gdb, bad news is you can't reliably do so for printing values. |
| 15:15:59 | krux02 | so basically you have to reimplement all `$` functions that you really care about in python with the API gdb provides. |
| 15:16:34 | krux02 | I did so for most basic types, such as string seq enum and set |
| 15:17:23 | FromGitter | <timotheecour> see note above regarding fact that gdb is not supported on latest OSX (mojave); and about my failed attempts at using `tools/nim-gdb.py` |
| 15:19:32 | FromGitter | <timotheecour> I’m really thinking we can have a cleaner solution that can allow to not just pretty-print but also call arbitrary code in nim during debugging session; that’d really help debugging, providing something more akin to how it’s easy to debug in Matlab/python |
| 15:21:13 | krux02 | gdb can be used to call arbitrary code, but that is not what you can reliably do when your program just crashed or most of your variables are still uninitualized memory pointing into illegal memory regions |
| 15:23:11 | FromGitter | <timotheecour> same note as above: ⏎ ⏎ > looking at DollarPrintFunction it requires $ to be instantiated in the binary otherwise the symbol won’t be available right? so if ur binary never calls $(Foo[float]) but u wanna echo a variable who has a Foo[float] field, how can it work? |
| 15:23:47 | krux02 | well it doesn't the printer has to do some fallback for that |
| 15:24:17 | krux02 | when you have a python printer, the existence of $ shouldn't matter. |
| 15:24:18 | FromGitter | <timotheecour> let me think for a day whether i can come up w POC based on RTTI |
| 15:24:46 | krux02 | but for enums there is no type information in the binary to print them when $ isn't used in the banary, so then I fall back to integer printing |
| 15:25:13 | krux02 | well first of all, you should get the existing solution to work on your computer. |
| 15:25:22 | krux02 | you can install Linux on apple computers |
| 15:25:36 | krux02 | even if it is in a VM it should work |
| 15:25:38 | FromGitter | <timotheecour> right, and lldb has same issue w enums; this is where the approach i’m working on could work |
| 15:26:17 | FromGitter | <timotheecour> correct, i shd try on linux since gdb is broken on osx |
| 15:27:32 | krux02 | gdb isn't great, it has a horrible terminal UI |
| 15:27:46 | krux02 | I use the emacs integration of gdb. |
| 15:27:57 | krux02 | that is the clunkiest debugger I ever used |
| 15:28:03 | krux02 | but it works |
| 15:28:16 | FromGitter | <timotheecour> well at least we both agree having a really good debugging experience is a must |
| 15:28:30 | krux02 | emacs and eclipse work as a gdb frontend. |
| 15:28:37 | krux02 | yes |
| 15:28:51 | krux02 | good debugging experience isn't something optional |
| 15:29:53 | krux02 | I think lldb support should also be supported |
| 15:30:31 | FromGitter | <timotheecour> lldb works fine on OSX, modulo fact that `tools/nim-gdb.py` would have to be adapted, but other than that works |
| 15:30:49 | krux02 | if you are able to do it, you can port the nim-gdb.py for the llvm API. it really isn't that much logic, I tried to keep everything minimal. |
| 15:31:11 | FromGitter | <timotheecour> (and modulo 1 bug i’ve reported specific to lldb, and 1 common to lldb/gdb) |
| 15:31:15 | krux02 | but you should start going crazy and add a ton of features and gimmics to the lldb backend. |
| 15:31:54 | krux02 | that isn't helpful, the implementation should stay minimal, as it break easily break when Nim changes. |
| 15:32:53 | krux02 | I don't know any modulo 1 bug |
| 15:34:31 | FromGitter | <timotheecour> https://github.com/nim-lang/Nim/issues/9753 and https://github.com/nim-lang/Nim/issues/9634 are the ones i was referring to |
| 15:36:16 | FromGitter | <timotheecour> when you get a chance i’d really appreciate if you could either comment or approve https://github.com/nim-lang/Nim/pull/9766 btw |
| 15:37:00 | FromGitter | <timotheecour> (i’ve addressed all ur past comments) |
| 15:41:12 | krux02 | timotheecour: there is a # todo: merge with getSymRepr |
| 15:41:33 | krux02 | I don't like these kind of comments |
| 15:41:47 | FromGitter | <timotheecour> i’ll remove it ; what other comments? |
| 15:43:13 | krux02 | so basically you enable a command line option for the compiler so that it prints full paths to the console all the time? |
| 15:43:13 | * | sheerluck quit (Quit: Leaving) |
| 15:43:39 | FromGitter | <alehander42> @krux02 the no enum RTTI unless `$` is instantiated should be fixed for debug mode |
| 15:43:39 | FromGitter | <timotheecour> done, removed the todo |
| 15:43:50 | FromGitter | <alehander42> i planned to do it , but not sure when |
| 15:44:58 | krux02 | alehander42: so you suggest in debug mode there is always RTTI for enums no matter if there is `$` instantiated for it or not? |
| 15:45:21 | FromGitter | <timotheecour> well that’s part of that PR, but yes, `—listFullPaths` now is supposed to be honored everywhere (and if not , we can fix remaining places in future PR’s) |
| 15:46:06 | FromGitter | <timotheecour> (in earlier version of that PR i had introduced another flag for that but araq told me to consolidate with listFullPaths instead of adding another one) |
| 15:46:14 | FromGitter | <alehander42> @krux02 yes, otherwise pretty printers suffer, as you said |
| 15:46:33 | FromGitter | <alehander42> and good pretty printing for enums/case objects is very important as they are very prevalent in nim code |
| 15:46:44 | krux02 | alehander42: I agree |
| 15:46:53 | FromGitter | <alehander42> (also rtti for case objects, NimDT_ stuff) |
| 15:46:59 | FromGitter | <alehander42> i can take a look tomorrow |
| 15:47:01 | FromGitter | <alehander42> if i have time |
| 15:47:34 | krux02 | it is annoying to debug the compiler with `print node`, it is very verbose. But I don't know how to implement the variant types in python/gdb |
| 15:47:53 | * | d10n-work joined #nim |
| 15:47:56 | krux02 | timotheecour: I think the PR is ok |
| 15:48:11 | krux02 | I would benefit from these changes |
| 15:48:49 | FromGitter | <alehander42> @krux02 i pretty print variants using a patched cgen which adds a bit of rtti for them |
| 15:48:51 | Araq | instantiating RTTI for debugging is the wrong idea IMO, instead use the .ndi file mechanism |
| 15:49:03 | FromGitter | <alehander42> but Araq told me i can do the same with the NimDT strucutres |
| 15:49:09 | FromGitter | <alehander42> just havent found the time to do it |
| 15:49:12 | FromGitter | <alehander42> I havent* |
| 15:49:35 | Araq | use the .ndi file mechanism |
| 15:52:56 | FromGitter | <alehander42> Araq, ndi files seem to only store mangling info ? |
| 15:53:11 | Araq | so make them store more crap |
| 15:53:56 | Araq | also -- I have no idea how "the compiler instantiated every $ for debugging" could work |
| 15:54:45 | FromGitter | <timotheecour> if we’re gonna store more crap, i really want it ndi to be stored json (or protobuf or …), not custom text format, otherwise won’t be fwd/backward compatible |
| 15:55:01 | Araq | it's always the same story. You have a *tooling* problem and afterwards the *language* has a new feature. |
| 15:55:15 | Araq | stop doing that. |
| 15:55:52 | Araq | case in point: system.once for hot code reloading. |
| 15:55:57 | FromGitter | <alehander42> i wanted to compiler to generate enum/NimDT rtti for each type, not every possible `$` |
| 15:56:10 | FromGitter | <alehander42> this seemed easy, ndi files might be ok too i guess |
| 15:56:24 | Araq | JSON for ndi is fine with me |
| 15:56:42 | * | Trustable joined #nim |
| 16:04:57 | Araq | C++'s string_view also applies. Ok, slicing copies and that's bad. C++'s solution: break the symmetry between input and output types, add string_view to the *language* so that everybody has to think about writing string_view instead of string for input parameters. More cognitive load. Alternative solution: teach your optimizer about the f(s.substr(...)) pattern. |
| 16:05:08 | * | btbytes joined #nim |
| 16:07:13 | FromGitter | <timotheecour> no broken symmetry with no null terminated string slices |
| 16:08:31 | Araq | And if you never find the resources to write an optimizer for the language in question (Nim?) because its type system turned into a black hole of sophistry (const T vs immutable T vs T), then maybe we need to rethink how we design programming languages. |
| 16:09:55 | Zevv | m/c |
| 16:09:56 | * | zyklon quit (Read error: Connection reset by peer) |
| 16:10:10 | Zevv | oops |
| 16:16:51 | * | hoijui quit (Ping timeout: 264 seconds) |
| 16:21:43 | Araq | "no broken symmetry"? Vector<string_view> cannot be used for Vector<string>, different representations |
| 16:22:00 | * | BigEpsilon quit (Ping timeout: 258 seconds) |
| 16:22:46 | FromGitter | <timotheecour> i was talking about D’s approach here, where it’s all string_view |
| 16:23:03 | FromGitter | <timotheecour> (well, not exactly string_view, but closer to string_view) |
| 16:23:33 | Araq | true but the price is an unclear ownership model and a GC that needs to be able to handle interior pointers |
| 16:23:56 | Araq | the unclear ownership doesn't matter because it's readonly, I know, I know. |
| 16:23:57 | FromGitter | <timotheecour> they’re verbotten |
| 16:24:05 | FromGitter | <timotheecour> in structs |
| 16:24:46 | * | asie quit (Ping timeout: 268 seconds) |
| 16:25:06 | FromGitter | <timotheecour> and ownership would be made even easier with nim’s superior thread local GC instead of D’s shared model |
| 16:25:22 | Araq | these things are hard but in the end I long for a Basic/Pascal-like language with metaprogramming |
| 16:26:07 | Araq | not for a C+=2 |
| 16:26:15 | Araq | or a C+=4 |
| 16:26:30 | FromGitter | <timotheecour> what do u mean? |
| 16:26:34 | * | zyklon joined #nim |
| 16:29:22 | FromGitter | <timotheecour> (and would allow us saving `sizeof(capacity)`bytes by removing `capacity` field, which disappears with D’s slices as it’s stored in GC segment instead of in each string/seq) |
| 16:30:28 | FromGitter | <timotheecour> that was a subtle point of the implementation |
| 16:32:04 | Araq | alternatively you can give dealloc() the size info your already have and save it in the allocator |
| 16:33:07 | Araq | or you invent a growonlySeq that checks if the size is a power of two (cheap 'and' instructions) in order to avoid storing a capacity |
| 16:34:07 | FromGitter | <timotheecour> `x=“abc”; x.setLen=0` => then capacity is lost with what u suggest? or im misunderstanding |
| 16:34:27 | FromGitter | <timotheecour> Oh, growonly |
| 16:34:34 | Araq | yeah, don't invent a growonlySeq, it cannot ever support reserve() |
| 16:34:35 | FromGitter | <timotheecour> but that’s very restrictive |
| 16:42:09 | * | endragor joined #nim |
| 16:47:26 | Araq | that's true but consider this: after AST construction every 'seq' in there doesn't change anymore and yet we keep the capacity on the heap |
| 16:48:10 | Araq | all this "waste", we need a caplessSeq[T] instead |
| 16:56:32 | * | btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:56:56 | * | BigEpsilon joined #nim |
| 16:58:30 | * | btbytes joined #nim |
| 17:25:49 | * | floppydh quit (Quit: WeeChat 2.3) |
| 17:32:45 | * | stefanos82 quit (Remote host closed the connection) |
| 18:12:41 | * | BigEpsilon quit (Ping timeout: 268 seconds) |
| 18:13:34 | * | snowolf joined #nim |
| 18:20:27 | * | theelous3 quit (Ping timeout: 258 seconds) |
| 18:21:14 | * | BigEpsilon joined #nim |
| 18:34:03 | * | rokups quit (Quit: Connection closed for inactivity) |
| 18:36:20 | * | BigEpsilon quit (Ping timeout: 250 seconds) |
| 18:41:07 | * | dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:44:20 | * | Tyresc joined #nim |
| 18:51:13 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 18:53:07 | * | sagax quit (Ping timeout: 244 seconds) |
| 19:13:30 | * | PMunch quit (Remote host closed the connection) |
| 19:16:53 | * | nsf quit (Quit: WeeChat 2.3) |
| 19:21:46 | * | hoijui joined #nim |
| 19:30:18 | * | hoijui quit (Remote host closed the connection) |
| 19:37:15 | * | hoijui joined #nim |
| 19:38:08 | * | theelous3_ joined #nim |
| 19:39:29 | * | endragor quit (Remote host closed the connection) |
| 19:41:34 | * | druonysus quit (Quit: druonysus) |
| 19:42:02 | * | druonysus joined #nim |
| 20:13:28 | FromDiscord_ | <moerm> Hello |
| 20:14:50 | shashlick | what's up |
| 20:18:14 | * | sagax joined #nim |
| 20:34:43 | * | btbytes quit (Quit: Textual IRC Client: www.textualapp.com) |
| 20:39:10 | FromDiscord_ | <moerm> Quick question: Can I, and if so how, force alignment (e.g. 16 Bytes) of an object or array variable? |
| 20:45:56 | FromDiscord_ | <exelotl> I haven't come across a good way to do it so far |
| 20:49:52 | FromDiscord_ | <treeform> Nim, like c/c++ will align your structures properly. But if you want specific alignment for network packets I would use streams and use the write/read interface. |
| 20:54:54 | FromDiscord_ | <moerm> I mean variable, not packets or streams |
| 20:58:58 | * | rect0x51 joined #nim |
| 21:05:32 | rayman22201 | That is a probably an araq or a mratsim question. You might have to emit the gcc aligned pragma to do it. |
| 21:07:11 | FromDiscord_ | <exelotl> that's one of the reasons I'm doing bindings for a GBA library instead of porting it or writing it from scratch |
| 21:07:31 | FromDiscord_ | <exelotl> there's just no way to guarantee the layout I need for certain hardware structures |
| 21:07:45 | dom96 | wat, I'm sure there is |
| 21:07:59 | dom96 | If you can do it in C then you can do it in Nim |
| 21:08:19 | FromDiscord_ | <moerm> rayman That's what I was thinking, too, yes. But I wanted a nicer Nim way. |
| 21:08:57 | rayman22201 | technically C doesn't allow you specify alignment either. the align attribute is a GCC extension... more of a compiler "hack" than a language feature. |
| 21:09:10 | dom96 | Anyway, I see at least one forum thread that can help you https://forum.nim-lang.org/t/2494 |
| 21:09:20 | FromDiscord_ | <moerm> exelotl No, rayman is right. One *can* do it via the emit pragma but it gets ugly |
| 21:09:43 | dom96 | I guess you should upvote this too https://github.com/nim-lang/Nim/issues/1930 |
| 21:09:46 | FromDiscord_ | <moerm> dom96 I'll have a look right away ... |
| 21:10:04 | dom96 | I should have probably said "might help you" :) |
| 21:11:34 | rayman22201 | It would be nice to be able to do bit packing directly in Nim. I would like to use Nim on an ESP8266 one day, and that would be very usefull for embedded. |
| 21:12:10 | narimiran | hey dom96, i don't know if you're watching your github notification, so i'll mention it here too: for the new blog post to appear tomorrow, i think you need to do some server-stuff thingy :) |
| 21:12:37 | dom96 | narimiran: if I do it now then it'll appear ahead of the date :) |
| 21:12:53 | dom96 | actually, jekyll might even do some magic and decide not to generate it |
| 21:13:11 | FromDiscord_ | <moerm> @dom96 OK, I looked. You were right, Thank you. the codegendecl pragma indeed is helpful (albeit still ugly, but nicer than a direct emit) |
| 21:13:12 | narimiran | yes, usually it is not generated until the date is not in the future |
| 21:13:26 | narimiran | i don't know how it works with this extra step |
| 21:13:36 | narimiran | (will it appear automatically tomorrow or not) |
| 21:13:37 | shashlick | dom96: what's your highest priority next for choosenim and nimble |
| 21:13:41 | FromDiscord_ | <exelotl> I'm struggling a lot with embedded at the moment... is this supposed to work with --os:standalone --gc:none? https://hastebin.com/raw/ukuhikalug |
| 21:13:58 | shashlick | I'm thinking of expanding the CI to osx and windows |
| 21:14:14 | dom96 | narimiran: jekyll literally just generates static html of whatever is there |
| 21:14:15 | FromDiscord_ | <exelotl> just a simple object instantiation gives "Error: system module needs: genericReset" |
| 21:14:19 | dom96 | only when I `git push` it |
| 21:14:38 | dom96 | narimiran: if you want you can change the date and I can push it now |
| 21:15:02 | dom96 | shashlick: for choosenim I would love binary builds |
| 21:15:03 | narimiran | dom96: if you'll be able to push it in the morning it is fine |
| 21:15:09 | dom96 | (+ better analytics) |
| 21:15:21 | dom96 | narimiran: only in the evening |
| 21:15:47 | narimiran | i guess it is fine too :) |
| 21:16:10 | dom96 | shashlick: for nimble it's lockfiles or an alternative, I want to research this well |
| 21:16:20 | narimiran | (i had changed the date from today to tomorrow, now i don't want to change it back again :D) |
| 21:17:25 | shashlick | I can setup nightlies as well for both |
| 21:17:28 | * | zyklon quit (Read error: Connection reset by peer) |
| 21:17:32 | narimiran | (nah, i'll change it, i think it is better that way, give me a minute or two) |
| 21:17:58 | dom96 | shashlick: by "binary builds" I mean choosenim should download the Nim nightlies |
| 21:19:40 | narimiran | dom96: changed the date. now it should all work and be visible once you do your thing :) |
| 21:20:17 | dom96 | done |
| 21:20:23 | shashlick | Oh yes sure |
| 21:20:35 | narimiran | dom96: thanks! |
| 21:20:42 | FromDiscord_ | <moerm> Btw, I'm just building some non trivial code for amd64 (nehalem+),, i386 (prescott+) and i386 (stoneage processors) with mainly Nim and some included C files and the Nim build system plus "when" constructs work nicely and are *much much* nicer and better than the old C way (make files, yuck). |
| 21:20:49 | FromDiscord_ | <moerm> So, Kudos to the Nim team! |
| 21:20:58 | * | narimiran goes to sleep, bye |
| 21:21:05 | FromDiscord_ | <moerm> cu |
| 21:21:27 | dom96 | moerm: yep, I love that about Nim as well :) |
| 21:22:25 | shashlick | dom96: ok then first i'll make a PR for windows binary release builds from the older one |
| 21:22:33 | shashlick | i'll put in the powershell zip extract hack for near term |
| 21:22:52 | shashlick | once i figure out nimarchive / nimgen / nimble stuff, we can move to that instead |
| 21:23:34 | * | narimiran quit (Quit: Leaving) |
| 21:24:48 | rayman22201 | @moerm awesome |
| 21:26:05 | rayman22201 | @exelotl, I think the person who did the Nintendo Switch support had similar issues and ended up just making a patch that implemented all the functions they needed in the system module under --os:switch |
| 21:26:56 | FromDiscord_ | <moerm> rayman ? Sorry, I'm working so I missed what your "awsome" relates to. Nim's build system, I guess? |
| 21:28:25 | rayman22201 | @moerm yes. |
| 21:28:54 | FromDiscord_ | <moerm> 😉 |
| 21:30:12 | rayman22201 | I was able to get Nim sort of working on AIX at one point. It was very pleasant getting a nice language on such an obscure OS and architecture. |
| 21:30:19 | FromDiscord_ | <moerm> Well noted, I'm even passing different switches to the **C** compiler depending on the processor target. Really cool what Nim offers there |
| 21:33:44 | * | NimBot joined #nim |
| 21:34:12 | * | zyklon joined #nim |
| 21:46:46 | shashlick | dom96: what do you want to do with https://github.com/dom96/choosenim/issues/88 |
| 21:48:09 | * | zachk joined #nim |
| 21:50:21 | * | Trustable quit (Remote host closed the connection) |
| 21:51:59 | * | zachk quit (Changing host) |
| 21:52:00 | * | zachk joined #nim |
| 21:53:46 | dom96 | shashlick: Happy with the PR, just wish there weren't other changes to readme/gitignore |
| 21:53:48 | * | Vladar quit (Remote host closed the connection) |
| 22:03:11 | shashlick | I guess you can edit it and merge per your requirements |
| 22:03:19 | shashlick | don't need to wait |
| 22:32:25 | shashlick | dom96: the windows binary install PR is ready - do you have time to review it now? |
| 22:32:34 | rayman22201 | @exelotl putting your let in a main function works. https://pastebin.com/raw/sLfB4xPH |
| 22:33:34 | rayman22201 | it's probably because of the way Nim top level / global variables are allocated |
| 22:33:40 | FromDiscord_ | <exelotl> ohhh |
| 22:34:00 | rayman22201 | nowhere to put that stuff with no gc and no os |
| 22:34:31 | FromDiscord_ | <exelotl> thanks so much, that solves a lot of my problems |
| 22:34:38 | rayman22201 | :thumbsup: |
| 22:35:04 | FromDiscord_ | <exelotl> there's one more thing I'm not sure about though, it's the same problem which this person had: https://forum.nim-lang.org/t/3910 |
| 22:35:19 | FromDiscord_ | <exelotl> wait |
| 22:35:22 | FromDiscord_ | <exelotl> sorry wrong thread |
| 22:36:06 | FromDiscord_ | <exelotl> this one: https://forum.nim-lang.org/t/3886 |
| 22:39:24 | FromDiscord_ | <exelotl> basically how to create a struct that goes into read-only memory (like data that's marked 'const' in C) |
| 22:40:16 | * | xet7 quit (Ping timeout: 264 seconds) |
| 22:41:35 | rayman22201 | Unfortunately, I don't think there is a good answer to that one, other than (again) dropping to C with an emit or a codegendecl pragma. |
| 22:43:01 | * | rect0x51 quit (Quit: WeeChat 2.3) |
| 22:43:14 | rayman22201 | I'm sad araq never answered that thread actually |
| 22:48:24 | * | krux02 quit (Remote host closed the connection) |
| 22:48:51 | FromDiscord_ | <exelotl> I'd be fine with using codegendecl for it, except I can't initialise a global object that way due to the previous issue |
| 22:48:57 | * | zyklon quit (Read error: Connection reset by peer) |
| 22:49:08 | Araq | previous issue? |
| 22:49:44 | FromDiscord_ | <exelotl> that this doesn't compile with --os:standalone --gc:none https://hastebin.com/raw/ukuhikalug |
| 22:50:45 | rayman22201 | The issue is that he wants a struct declared as a global const so that it ends up in the RO memory of his embedded chip, yes? |
| 22:51:05 | rayman22201 | i.e. it has to be outside the nim init code |
| 22:52:33 | * | xet7 joined #nim |
| 22:53:42 | FromDiscord_ | <exelotl> yeah what rayman said x) |
| 22:54:41 | Araq | oh not that bullshit again |
| 22:54:49 | rayman22201 | lol |
| 22:55:07 | Araq | I'll remove --os:standalone and --gc:none |
| 22:56:06 | Araq | just compile your program with -d:noSignalHandler and maybe -d:useMalloc and maybe --gc:regions |
| 22:56:11 | rayman22201 | You don't want Nim to work on embedded? or you think this is the wrong way to do it? |
| 22:57:12 | Araq | "embedded" works fine, it's just these switches, they are stupid |
| 22:57:21 | rayman22201 | putting data in a RO memory is an important part of embedded development. |
| 22:57:28 | rayman22201 | There should be a way to do it |
| 22:57:38 | Araq | that's covered by .codegenDecl |
| 22:59:22 | rayman22201 | except that codegenDecl can't move code around, only emit new code in the spot. |
| 23:00:31 | Araq | "move around"? it's readonly data |
| 23:01:14 | rayman22201 | move the text, so the compiler puts it in the right place. Let me rephrase the question |
| 23:02:09 | rayman22201 | declaring a struct as a global const at the top of a C file, will put that struct into RO memory (mostly by convention because that's what the embedded C compilers decided to do.) |
| 23:02:20 | rayman22201 | How would do this in Nim? |
| 23:03:37 | * | Ven`` joined #nim |
| 23:03:52 | Araq | var x {.codegenDecl: "const $# $# = {1, 2}".}: MyStruct |
| 23:04:04 | dom96 | Araq: Please don't just willy nilly remove that |
| 23:04:10 | dom96 | I use that flag and I'm sure many others do too |
| 23:04:37 | Araq | I never take good stuff away. |
| 23:05:03 | Araq | when I tell you you don't need them to develop kernels. Chances are, I'm right. |
| 23:05:33 | rayman22201 | I believe you. I just don't know the answer. That's why I'm asking :-) |
| 23:05:49 | Araq | the codegen was designed to only compile what you use, if your program doesn't use the GC, it won't be in your binary |
| 23:06:52 | Calinou | hi, my Nim t-shirt is on the way :) |
| 23:06:53 | * | zyklon joined #nim |
| 23:06:57 | Araq | there are some parts in system.nim that need refactoring but --os:standalone --gc:none is like using a chainsaw to cut your bread |
| 23:07:05 | * | hoijui quit (Remote host closed the connection) |
| 23:07:10 | Calinou | I released a new version of my package (clr) to fix building with 0.19.0 since I forgot to make a release before |
| 23:08:35 | Calinou | I need to look into static linking OpenSSL/PCRE too, so Windows binaries don't need DLLs alongside |
| 23:08:42 | FromDiscord_ | <exelotl> Araq: --os:standalone is necessary right? my toolchain is missing much of the C standard library so --os:linux won't work, and also the generated C code is quite heavy |
| 23:09:11 | FromDiscord_ | <exelotl> e.g. the generated stdlib_system.c has static TNimNode TM_Q5wkpxktOdTGvlSRo9bzt9aw_0[108]; |
| 23:09:46 | FromDiscord_ | <exelotl> (when compiled with os:linux) |
| 23:12:33 | Araq | there is a switch to make use Nim its own memset calls and Nim doesn't need malloc(), the TNimNode means you used a construct that uses RTTI |
| 23:14:45 | Araq | most problems are caused by programmers who compile 'echo "hi"' for the device that lacks an OS, a filesystem and a display... |
| 23:15:59 | FromDiscord_ | <exelotl> this is my entire program: https://hastebin.com/raw/ukuhikalug |
| 23:16:51 | Araq | put it in a main proc |
| 23:22:39 | FromDiscord_ | <exelotl> the TNimNode stuff is still there even with a totally empty nim program, from what I can tell this is just a consequence of switching to --os:linux |
| 23:24:12 | * | oz joined #nim |
| 23:27:18 | rayman22201 | @araq was right (no surprise there lol). @exelotl this produces exactly the right C output: https://pastebin.com/raw/eqgLhY2m |
| 23:27:44 | rayman22201 | and compiles correctly with no gc / no os |
| 23:29:27 | FromDiscord_ | <exelotl> ouch so you have to embed the values into the codegendecl? |
| 23:29:39 | FromDiscord_ | <exelotl> that's really not ideal |
| 23:30:22 | rayman22201 | It's const going into RO data. Considering that, it's not terrible. |
| 23:30:24 | FromDiscord_ | <moerm> @exelotl re your question: I just happened to use (and inspect the result) of .codegenDecl. And YES it works fine and you can use it to e.g. enforce something being const |
| 23:33:32 | FromDiscord_ | <moerm> @exelotl "not ideal"? I don't see any significant problem with writing ``foo {.codegenDecl: "const $# $#".}: BazType`` instead of "foo: BazType". In fact a decent editor should offer you a way to automatize that |
| 23:34:26 | rayman22201 | It's the struct member values initialization that is bothering @exelotl I believe |
| 23:34:41 | rayman22201 | not the cdecl itself |
| 23:34:49 | FromDiscord_ | <moerm> Oh, and: NO you don't need to embed your vars/consts. The pragma is literally the same for all your const stuff. |
| 23:36:11 | FromDiscord_ | <moerm> struct members? Yuck. Maybe Araq has a cool way. I only used it for simple stuff (in my case var alignment) |
| 23:36:37 | rayman22201 | If you look at the pastebin I just posted, you can see what we are talking about. |
| 23:36:44 | FromDiscord_ | <exelotl> as in I can't do this let a {.codegenDecl: "const $# $#".} = Foo(x:10, y:20) |
| 23:37:16 | rayman22201 | that has other problems @exeltol, because Foo(x:10, y:20) in a global scope is going to allocate. |
| 23:37:59 | FromDiscord_ | <exelotl> yeah |
| 23:38:17 | FromDiscord_ | <moerm> I guess .codegenDecl is for var *decl* - not for initilialization. I guess, Araq will be more than happy to correct me if I'm wrong *g |
| 23:38:17 | rayman22201 | that's why using a main() function is really your best bet in general |
| 23:38:54 | rayman22201 | well, as we said, the codegenDecl, does initialize the const correctly. |
| 23:39:43 | FromDiscord_ | <moerm> but not the way exelotl needs it |
| 23:39:57 | FromDiscord_ | <moerm> I guess he'll have to fall back to .emit |
| 23:40:00 | rayman22201 | codegenDecl isn't about "decling" it's declaring a codegen node for the generator |
| 23:41:57 | rayman22201 | pragmas can be used with macros. You could make the syntax look nicer with macros. |
| 23:42:21 | FromDiscord_ | <exelotl> what I was hoping is that the value of `a` is something I could arrive at, at compile time, and then have it be placed in RO data |
| 23:42:37 | FromDiscord_ | <exelotl> which could be really useful for things like converting graphics, generating lookup tables, etc. |
| 23:43:11 | rayman22201 | Nim has const for compile time execution |
| 23:43:36 | * | theelous3_ quit (Ping timeout: 258 seconds) |
| 23:43:40 | rayman22201 | https://nim-lang.org/docs/manual.html#statements-and-expressions-const-section |
| 23:44:00 | FromDiscord_ | <exelotl> yep, but let a = myConst stil causes allocation when used at the top-level |
| 23:44:38 | rayman22201 | Then don't use top level? |
| 23:44:42 | rayman22201 | use a main function lol |
| 23:45:27 | FromDiscord_ | <exelotl> but... I can't have something go into RO data if I put it inside a main function, right? |
| 23:48:04 | FromDiscord_ | <exelotl> this feels like a big catch 22 to me :') |
| 23:52:56 | FromGitter | <mratsim> let foo {.global.} ? |
| 23:53:09 | rayman22201 | this works fine: https://pastebin.com/raw/q7Vc28fS |
| 23:53:17 | rayman22201 | outputs exactly the correct C code |
| 23:54:09 | * | leorize quit (Quit: WeeChat 2.3) |
| 23:54:17 | rayman22201 | a is a global const of type Foo that is declared at the top of the file. GCC should stick that right in the RO section. |