| 00:01:07 | * | apotheon joined #nim |
| 00:08:36 | * | francisl quit (Quit: francisl) |
| 00:13:47 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:17:15 | * | derka quit (Quit: derka) |
| 00:20:45 | * | Demon_Fox joined #nim |
| 00:23:25 | ephja | the 'guard' pragma seems to accept anything, but it doesn't do anything if the argument is not a Lock |
| 00:24:26 | * | desophos quit (Ping timeout: 256 seconds) |
| 00:27:35 | ldlework | How do you get a sequence of a Table's keys?! |
| 00:27:49 | ldlework | I can't call keys() I can only iterate over it? |
| 00:27:52 | filwit | tablet.keys.toSeq |
| 00:29:01 | filwit | sequtils.toSeq(anyIterator) |
| 00:29:35 | * | lompik joined #nim |
| 00:29:39 | filwit | though I no idea what kind of overhead that has |
| 00:32:27 | ldlework | its horrible lol |
| 00:32:37 | filwit | why? |
| 00:32:50 | ldlework | I don't know, but when I did it each frame I got like 2 fps |
| 00:32:54 | ldlework | or rather |
| 00:33:05 | ldlework | when I did it hundreds of times a frame, I got like 2 FPS |
| 00:33:15 | filwit | oh, horrible performance, i thought you meant the design was horrible |
| 00:33:17 | ldlework | when I did it once a frame I got 100s of FPS |
| 00:33:55 | filwit | yeah it's probably causing a bunch of small allocations (bad for a GC) cause it's can't predict the length of the seq to return |
| 00:34:15 | * | jaco60 quit (Ping timeout: 240 seconds) |
| 00:34:42 | filwit | you could always make your own more efficient version for tables using the length to pre-alloc the seq, then just fill it in |
| 00:35:30 | filwit | (that should probably be part of the 'tables' lib, i agree... I'm sure the powers that be would accept a PR like that) |
| 01:00:23 | * | desophos joined #nim |
| 01:24:39 | * | brson_ joined #nim |
| 01:26:40 | * | brson quit (Ping timeout: 250 seconds) |
| 01:38:19 | * | francisl joined #nim |
| 01:49:48 | * | francisl quit (Quit: francisl) |
| 02:06:52 | * | gokr quit (Quit: Leaving.) |
| 02:11:32 | * | saml_ joined #nim |
| 02:15:19 | Varriount | ldlework: If your keys are strings, try marking them with shallow(), that should help with allocations. |
| 02:24:01 | * | zepolen joined #nim |
| 03:04:09 | * | pregressive joined #nim |
| 03:07:13 | * | darkf quit (Quit: Leaving) |
| 03:14:56 | * | brson_ quit (Ping timeout: 240 seconds) |
| 03:25:39 | * | vendethiel joined #nim |
| 03:31:26 | * | ephja quit (Ping timeout: 256 seconds) |
| 03:32:46 | * | junw_ quit (Ping timeout: 250 seconds) |
| 03:35:25 | * | francisl joined #nim |
| 03:43:03 | * | saml_ quit (Remote host closed the connection) |
| 03:47:51 | * | zepolen quit (Remote host closed the connection) |
| 03:48:20 | ldlework | Why am I getting undeclared field: 'keysym' with https://gist.github.com/dustinlacewell/88cda9abd9c344c465c8 |
| 03:48:39 | ldlework | Doesn't using case on the kind allow me to access the fields? |
| 03:52:23 | Varriount | ldlework: What's the event type look like? |
| 03:54:01 | ldlework | https://github.com/nim-lang/sdl2/blob/master/src/sdl2.nim#L55 |
| 03:55:51 | ldlework | oh wait I think I remember something about |
| 03:55:58 | filwit | you have to cast SDL events to the specific event type |
| 03:56:01 | ldlework | the data being hidden under a kind specific attribute |
| 03:56:08 | ldlework | no |
| 03:56:20 | ldlework | there's some template that does something.. |
| 03:57:03 | ldlework | ah here it is, https://github.com/nim-lang/sdl2/blob/master/src/sdl2.nim#L600 |
| 03:58:22 | filwit | anyways, g2g |
| 03:58:27 | * | filwit quit (Quit: Leaving) |
| 03:59:46 | * | lompik quit (Ping timeout: 240 seconds) |
| 04:02:40 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 04:06:52 | * | zepolen joined #nim |
| 04:19:01 | * | endragor joined #nim |
| 04:36:50 | * | francisl quit (Quit: francisl) |
| 04:55:40 | * | hh_ joined #nim |
| 04:58:37 | * | pregressive quit (Remote host closed the connection) |
| 05:00:43 | * | hh_ quit (Quit: Page closed) |
| 05:01:05 | * | pregressive joined #nim |
| 05:09:02 | * | vangroan joined #nim |
| 05:12:13 | * | vangroan quit (Client Quit) |
| 05:12:50 | * | pregressive quit (Remote host closed the connection) |
| 05:13:09 | * | pregressive joined #nim |
| 05:15:01 | * | pregressive quit (Remote host closed the connection) |
| 05:38:39 | * | lqdc quit (Ping timeout: 252 seconds) |
| 05:39:09 | * | vendethiel joined #nim |
| 05:42:33 | * | pregressive joined #nim |
| 05:44:51 | ThePythonicCow | Several hours ago, fitwit wrote "yeah it's probably causing a bunch of small allocations (bad for a GC)" |
| 05:47:08 | ThePythonicCow | I'm jumping in way over my head here, but if nim knows (can generate code at compile time that can calculate efficiently at runtime) the length of what's free'd, then a custom allocator that pools the most commonly used small sizes can really speed things up. I "saved" a C++ project that was in trouble for unacceptable performance doing this, back in the 1990's. |
| 05:48:51 | ThePythonicCow | Plain old C free() can't do that , because it only has the pointer, not the length, so it has to go back to the primary malloc pool to figure out what it's freeing. |
| 05:49:30 | ThePythonicCow | But when you're working a level up from plain old C, there's a good chance you have or can get the length, cheaply. |
| 05:52:41 | ThePythonicCow | So, back then, I had something like 16 pools of memory, for one to sixteen word lengths, and if anyone wanted to buy or sell a short length, I did it off those pools, for just a few inline instructions. If a pool ran out, I malloc'd another page of memory, for more of that particular size. |
| 05:56:07 | * | s4 joined #nim |
| 06:00:47 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 06:02:07 | * | ephja joined #nim |
| 06:08:18 | * | pregressive quit (Remote host closed the connection) |
| 06:10:02 | * | StarBrilliant quit (Ping timeout: 250 seconds) |
| 06:23:48 | * | StarBrilliant joined #nim |
| 06:43:31 | * | endragor quit (Remote host closed the connection) |
| 06:45:32 | * | endragor joined #nim |
| 06:46:28 | * | endragor quit (Read error: Connection reset by peer) |
| 06:46:34 | * | endragor_ joined #nim |
| 06:50:56 | * | Demon_Fox quit (Ping timeout: 240 seconds) |
| 06:57:51 | * | Demon_Fox joined #nim |
| 07:14:18 | * | gour joined #nim |
| 07:18:56 | * | yglukhov joined #nim |
| 07:23:04 | * | vendethiel joined #nim |
| 07:23:16 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 07:26:03 | * | filcuc joined #nim |
| 07:26:27 | * | warkid joined #nim |
| 07:29:04 | * | gokr joined #nim |
| 07:44:58 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 07:50:54 | * | vendethiel joined #nim |
| 07:59:02 | gokr | Morning |
| 08:00:01 | gokr | Battled last night with getting a "blink-the-LED" program running on a Linkit One. So frustrating, now all compiles and links properly but ... nah, won't blink the damn thing. |
| 08:05:44 | * | endragor_ quit (Remote host closed the connection) |
| 08:11:22 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 08:12:26 | * | apotheon quit (Ping timeout: 240 seconds) |
| 08:13:45 | * | yglukhov joined #nim |
| 08:14:51 | * | Demon_Fox_ joined #nim |
| 08:15:56 | * | Demon_Fox quit (Ping timeout: 240 seconds) |
| 08:24:42 | * | apotheon joined #nim |
| 08:28:55 | * | Arrrr joined #nim |
| 08:30:42 | * | Demon_Fox_ quit (Remote host closed the connection) |
| 08:31:08 | * | endragor joined #nim |
| 08:55:34 | * | Sembei quit (Quit: WeeChat 1.5-dev) |
| 08:57:46 | * | zepolen quit (Remote host closed the connection) |
| 08:58:56 | * | Trustable joined #nim |
| 09:00:05 | * | hh_ joined #nim |
| 09:02:41 | * | coffeepot joined #nim |
| 09:03:12 | Varriount | To anyone listening: A new version of NimLime is out! |
| 09:03:36 | Varriount | ThePythonicCow: You'll be interested to know it's written in Python. :D |
| 09:06:02 | coffeepot | grats Varriount! |
| 09:07:46 | Varriount | coffeepot: The biggest thing for me was the reworked backend and error reporting system. |
| 09:08:31 | coffeepot | excellent, does it support code completion? |
| 09:08:50 | coffeepot | just read, yes it does :) |
| 09:09:18 | Varriount | coffeepot: Well, Sublime Text supports a kind of code completion out of the box, however the plugin doesn't have that level of integration with Nimsuggest yet. |
| 09:10:23 | coffeepot | nice, looks good :) |
| 09:23:29 | * | derka joined #nim |
| 09:24:26 | * | zepolen joined #nim |
| 09:28:59 | * | toaoMgeorge quit (Ping timeout: 276 seconds) |
| 09:32:06 | ThePythonicCow | I'll check out the new NimLime ... I tried earlier, but failed, to add it to Sublime, my preferred gui editor, when I'm not using my favorite editor of all time, ed. |
| 09:32:39 | ThePythonicCow | I did not bother to figure out why my first attempt to use NimLime failed ... no coherent comments to provide there |
| 09:51:00 | gokr | Araq: How does it work with bool and c2nim? I mean... can one generally pass true/false to C and it ends up correct? |
| 09:52:39 | endragor | NIM_BOOL is defined as `unsigned char` if the compiler doesn't support `bool` type |
| 09:52:42 | endragor | true/false is 1/0 |
| 09:56:37 | gokr | mmm |
| 09:56:59 | * | toaoMgeorge joined #nim |
| 09:57:09 | gokr | Araq: Btw, ended up getting "mod_core_base* {.importc: "mod_core_base".} {.bitsize: 1.}: VMUINT" - bug not merging pragmas? |
| 09:58:19 | yglukhov | isnt getEnv+js+compileTime a solved issue by now? |
| 09:59:47 | endragor | I can't forward-declare a type in Nim, can I? I'm trying to interface with C++ framework with lots of inter-dependencies between classes. Would be nice to declare all the types first, and then provide implementations for them in separate files. Seems the only way to do that is to declare types first and interface fields as zero-arg procedures instead of actual variables. Any other workaround? |
| 10:01:07 | * | yglukhov_ joined #nim |
| 10:02:32 | * | mlitwiniuk quit (Quit: over and out) |
| 10:02:51 | * | mlitwiniuk joined #nim |
| 10:04:00 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 10:04:21 | * | mlitwiniuk quit (Client Quit) |
| 10:04:34 | * | mlitwiniuk joined #nim |
| 10:06:45 | * | zepolen quit (Ping timeout: 245 seconds) |
| 10:08:22 | * | zepolen joined #nim |
| 10:11:42 | * | yglukhov_ quit (Remote host closed the connection) |
| 10:14:08 | Varriount | endragor: Nope. Types can't be forward-declared, however types defined in the same section can reference each other without regards to order. |
| 10:19:38 | * | yglukhov joined #nim |
| 10:23:27 | * | gour_ joined #nim |
| 10:26:14 | * | gour quit (Ping timeout: 256 seconds) |
| 10:30:09 | * | irrequietus joined #nim |
| 10:38:35 | * | zepolen quit (Ping timeout: 240 seconds) |
| 10:41:52 | * | yglukhov quit (Remote host closed the connection) |
| 10:42:17 | * | zepolen joined #nim |
| 10:46:39 | * | warkid quit (Ping timeout: 252 seconds) |
| 10:49:04 | * | junw_ joined #nim |
| 10:53:11 | def- | endragor: one approach is to have a types.nim file and define all types there. if they all interact with each other, it's not a bad idea to define them in the same place |
| 10:54:36 | endragor | def-: they interact with each other via methods, not fields. I'd like to avoid declaring fields and methods related to the same class in separate files |
| 10:55:53 | endragor | the only way I've found so far is to declare "naked" types in one place, and then declare both vars and methods for one class in one file, but convert `var` declaration into two procedures with a macro |
| 10:56:03 | endragor | (set procedure and get procedure) |
| 11:02:13 | * | yglukhov joined #nim |
| 11:02:32 | * | zepolen quit (Ping timeout: 250 seconds) |
| 11:07:05 | * | zepolen joined #nim |
| 11:17:59 | * | hh_ quit (Quit: Page closed) |
| 11:30:34 | * | zepolen quit (Read error: Connection reset by peer) |
| 11:33:35 | * | zepolen joined #nim |
| 11:38:06 | * | zepolen_ joined #nim |
| 11:38:08 | * | zepolen quit (Read error: Connection reset by peer) |
| 11:44:05 | ThePythonicCow | Varriount: I am still getting failures trying to use NimLime with my Sublime install. I got past the first of the 4 error screens by adding the directory with nimsuggest to my $PATH but now it still cannot find nim or nimble, and an strace shows it is looking for $PATH/nim.exe (the entire $PATH, with its dozen directories, as a single string), rather than looking for x/nim, for each x in $PATH |
| 11:44:29 | ThePythonicCow | This is on Debian Linux, running zsh, a Bourne Shell extension |
| 11:52:52 | yglukhov | Araq: mind for a conditionalSymbolValue() magic to allow cmdline -d:myConditionalString=someStringValue? |
| 11:57:51 | * | zepolen_ quit (Read error: Connection reset by peer) |
| 11:57:56 | * | filwit joined #nim |
| 11:59:04 | * | wuehlmaus quit (Quit: Lost terminal) |
| 11:59:19 | Arrrr | Related http://stackoverflow.com/questions/34119841/define-switch-for-key-value |
| 12:00:05 | * | zepolen joined #nim |
| 12:01:25 | filwit | ThePythonicCow said: "... Plain old C free() can't do that , because it only has the pointer, not the length, so it has to go back to the primary malloc pool to figure out what it's freeing." |
| 12:02:40 | yglukhov | on the other hand, env + staticExec + echo $MY_VAR should do the trick... although a bit hacky... |
| 12:02:41 | filwit | FYI, Nim does use it's own allocator, not malloc/free.. and (apparently) that does make use of type-size information rather than store size as a header like malloc does |
| 12:03:29 | ThePythonicCow | filwit: << Nim does use it's own allocator, >> cool |
| 12:04:28 | filwit | ThePythonicCow: IDK much about it's details beyond that point.. though I know it allocates by pages (mmap, MapVirtualAddress) and uses bit patterns or something to help the GC understand what is a live reference |
| 12:05:01 | ThePythonicCow | ok |
| 12:05:36 | ThePythonicCow | if I stay with Nim long enough ... I'll know the details ... but that's a ways off into the future |
| 12:06:24 | filwit | that said, the GC still has to do cyclic scans and stuff, so lots of small allocations aren't good (of course, it only needs to do that on potentially cyclic types, which strings aren't so it's probably true that it wasn't a huge performance concern) |
| 12:07:35 | filwit | I was referring to the sequtils.toSeq() function which takes any iterator and converts it into a seq.. which means it can't really predict the size of the seq beforehand, and probably causes a bunch of small alloc/realloc equivalents in the allocator |
| 12:10:31 | filwit | for something like a Table where you want an seq of keys, it would probably be more efficient to have a special keysSeq() proc which used the size-info |
| 12:10:51 | filwit | anyways.. just commenting on that cause you quoted me about it earlier, cheers :) |
| 12:16:35 | * | exebook joined #nim |
| 12:21:27 | * | zepolen quit (Read error: Connection reset by peer) |
| 12:21:55 | gokr | I am totally confused over how nim decides what C header files it includes. |
| 12:25:21 | * | zepolen joined #nim |
| 12:29:36 | * | desophos quit (Read error: Connection reset by peer) |
| 12:37:00 | * | BitPuffin joined #nim |
| 12:48:47 | * | warkid joined #nim |
| 12:50:30 | * | zepolen quit (Ping timeout: 245 seconds) |
| 12:51:47 | * | Arrrr quit (Ping timeout: 276 seconds) |
| 12:52:42 | * | zepolen joined #nim |
| 12:53:33 | * | Arrrr joined #nim |
| 13:08:28 | * | zepolen quit (Read error: Connection reset by peer) |
| 13:10:53 | * | zepolen joined #nim |
| 13:22:17 | * | gokr quit (Quit: Leaving.) |
| 13:22:38 | * | gokr joined #nim |
| 13:22:49 | * | irrequietus quit () |
| 13:26:56 | * | zepolen quit (Ping timeout: 240 seconds) |
| 13:27:38 | * | zepolen joined #nim |
| 13:28:52 | * | lompik joined #nim |
| 13:42:42 | * | s4 quit (Quit: Konversation terminated!) |
| 13:44:09 | * | zepolen quit (Read error: Connection reset by peer) |
| 13:46:58 | * | zepolen joined #nim |
| 13:56:20 | * | toaoMgeorge quit (Ping timeout: 252 seconds) |
| 13:56:49 | * | zepolen quit (Read error: No route to host) |
| 13:57:25 | * | zepolen joined #nim |
| 14:00:20 | * | zepolen quit (Read error: Connection reset by peer) |
| 14:04:22 | * | zepolen joined #nim |
| 14:16:31 | * | hh_ joined #nim |
| 14:18:11 | * | lompik quit (Ping timeout: 264 seconds) |
| 14:19:54 | * | zepolen quit (Read error: Connection reset by peer) |
| 14:22:40 | * | zepolen joined #nim |
| 14:29:42 | ThePythonicCow | Varriount: Your nimlime_core/utils/misc.py:def split_semicolons(string) routine (if that's your code) does not work on Linux |
| 14:29:56 | ThePythonicCow | As described here: http://stackoverflow.com/questions/4528438/classpath-does-not-work-under-linux |
| 14:30:13 | ThePythonicCow | the PATH component separator on Linux is colon ':', not semicolon ';' |
| 14:31:07 | ThePythonicCow | So nimlime is not loading for me on Linux, because it cannot find nim or nimble |
| 14:31:44 | ThePythonicCow | It ends up looking for a file that has a path that is my entire (100 char, multiple dirs) $PATH long |
| 14:34:09 | ThePythonicCow | The Python char os.pathsep should work reliably, on any OS |
| 14:34:32 | ThePythonicCow | (colon or semicolon, as the case be) |
| 14:34:49 | * | zepolen quit (Read error: Connection reset by peer) |
| 14:36:08 | * | zepolen joined #nim |
| 14:40:30 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 14:43:01 | * | regtools joined #nim |
| 14:45:14 | ThePythonicCow | I filed a nimlime bug on git, as I should have done: "nimline cant load nim or nimble using Linux PATH (colon, not semicolon PATH sep) #59 " |
| 14:49:48 | onionhammer | @Varriount https://www.sublimetext.com/docs/3/syntax.html |
| 14:50:20 | * | gour_ quit (Quit: WeeChat 1.4) |
| 14:50:29 | * | darkf joined #nim |
| 14:53:20 | * | gour joined #nim |
| 14:54:47 | * | arnetheduck joined #nim |
| 14:55:11 | * | hh_ quit (Quit: Page closed) |
| 14:55:30 | * | zepolen quit (Ping timeout: 245 seconds) |
| 14:58:26 | * | zepolen joined #nim |
| 15:06:03 | * | pregressive joined #nim |
| 15:06:12 | * | pregressive quit (Remote host closed the connection) |
| 15:23:49 | * | zepolen quit (Read error: Connection reset by peer) |
| 15:26:11 | * | krux02 joined #nim |
| 15:27:45 | * | zepolen joined #nim |
| 15:45:45 | * | zepolen_ joined #nim |
| 15:46:18 | * | wuehlmaus joined #nim |
| 15:48:10 | * | zepolen quit (Ping timeout: 260 seconds) |
| 15:55:16 | * | zepolen_ quit (Read error: Connection reset by peer) |
| 15:55:51 | * | zepolen joined #nim |
| 16:00:03 | krux02 | I have problems creating the `[]` operator for my own type, how is it done properly? |
| 16:00:40 | coffeepot | proc `[]`*(myType: MyType) = |
| 16:00:59 | coffeepot | or you mean dereferencing? |
| 16:01:52 | * | pregressive joined #nim |
| 16:02:08 | * | zepolen_ joined #nim |
| 16:03:01 | * | zepolen quit (Read error: Connection reset by peer) |
| 16:05:11 | krux02 | coffeepot: here I made an example https://gist.github.com/krux02/390e68e6e5e6c5cb4e01 |
| 16:05:31 | krux02 | I always end up getting an error no matter how I implement it |
| 16:05:51 | krux02 | the [] operator needs to support read write and update |
| 16:06:53 | * | jaco60 joined #nim |
| 16:07:11 | krux02 | read seems to be no problem at all, but += seems to be a problem all the time |
| 16:07:19 | coffeepot | first look but there must be an easier way to do this (cast[ptr[T]](cast[int](mb.data) + (index * sizeof(T))))[] |
| 16:08:11 | coffeepot | not that i have a suggestion atm lol |
| 16:08:11 | krux02 | that part is not the problem |
| 16:08:28 | krux02 | it is for a c api wrapper |
| 16:08:33 | coffeepot | ah right |
| 16:08:53 | krux02 | and the cpai thinks that there is pointer arithmetic |
| 16:12:07 | krux02 | the problem is, that it is a low level api, and copying everything into a seq is not feasable |
| 16:12:24 | krux02 | is there a seqView class somewhere that I can abuse? |
| 16:17:29 | * | zepolen_ quit (Read error: Connection reset by peer) |
| 16:17:57 | * | zepolen joined #nim |
| 16:18:29 | coffeepot | i have no idea :) I heard that seqs are compatible with C arrays though, maybe someone with more knowledge can chip in? |
| 16:20:08 | coffeepot | i suspect you can go var s: newSeq[int](10); s[0].addr to work with C |
| 16:20:18 | coffeepot | thinking about it, pretty sure I did this in my odbc lib |
| 16:20:55 | * | ryu0 joined #nim |
| 16:20:57 | * | ryu0 left #nim ("WeeChat 1.0.1") |
| 16:21:14 | Araq | krux02: did you try to make it return 'var T' ? |
| 16:21:33 | coffeepot | by the way, you missed off the `[]=` proc for your first type, mappedbufferA |
| 16:21:46 | coffeepot | which is the cause of the error at line 17 |
| 16:21:48 | krux02 | Araq: https://gist.github.com/krux02/390e68e6e5e6c5cb4e01 |
| 16:21:54 | krux02 | yes it is the first one |
| 16:22:30 | krux02 | coffeepot: if I add the `[]=` for the first type, then I get ambiguety |
| 16:23:00 | coffeepot | really? works for me? |
| 16:23:09 | coffeepot | proc `[]=`*[T](mb : MappedBufferA[T]; index: int; value : T) = |
| 16:24:21 | coffeepot | adding in var T at line 24 seems to fix the 2nd issue |
| 16:24:42 | coffeepot | although the code segfaults :) |
| 16:24:59 | * | jaco60 quit (Quit: Leaving) |
| 16:25:18 | coffeepot | https://gist.github.com/coffeepots/1c8caf3382372dbf21d6 |
| 16:25:24 | * | jaco60 joined #nim |
| 16:25:24 | filwit | krux02: haven't looked at your gist, but just a comment on wrapping C arrays.. I find it's much easier to make an ``type CArray{.unchecked.}[T] = array[1,T]`` and use ``ptr CArray[T]`` than it is to use plain ``ptr T`` + pointer arithmetic to access elements |
| 16:26:05 | filwit | krux02: with the `CArray` version you can simple use the [] to access elements inside the array |
| 16:26:08 | coffeepot | yes! That's (what filwit said) the way to do it :) |
| 16:26:36 | krux02 | sorry I tested it with the `[]=` for the first type now, and now it works |
| 16:26:38 | coffeepot | that's how i did it in odbc too |
| 16:27:00 | coffeepot | highly recommend using the unchecked arrays, will make your life easier I feel |
| 16:27:04 | krux02 | I actually tested it already earlier and got a compile error with ambiguety, but propably there was a typo somewhere |
| 16:27:23 | krux02 | what is unchecked arrays? |
| 16:27:31 | krux02 | is it doing what I want to do? |
| 16:27:51 | coffeepot | unchecked arrays are basically arrays that don't check length IIRC |
| 16:27:59 | coffeepot | compatible with C |
| 16:28:06 | filwit | coffeepot: yep, so much easier.. plus using CArray[T] gives you more information about what's going on with the structure |
| 16:28:29 | krux02 | so they are called CArray[T]? |
| 16:28:43 | coffeepot | except you can use [] to access them and it automatically does the pointer arith for you based on the type size |
| 16:28:43 | filwit | you have to define it like I showed |
| 16:29:08 | coffeepot | as filwit said, first define the type: type CArray{.unchecked.}[T] = array[1,T] |
| 16:29:20 | krux02 | can you give me a link to an example or usage? |
| 16:29:31 | filwit | krux02: sure, one sec |
| 16:30:34 | coffeepot | this is how i do it in odbc, where i need to be able to cast to different types for the same data block: |
| 16:30:37 | coffeepot | type UncheckedArray {.unchecked.} [t] = array[0,t] |
| 16:30:47 | coffeepot | type SQLByteArrayUC = ptr UncheckedArray[byte] |
| 16:30:57 | coffeepot | type Utf16ArrayUC = ptr UncheckedArray[Utf16Char] |
| 16:31:17 | coffeepot | then I can simply cast[SQLByteArrayUC](buffer) for example |
| 16:31:26 | coffeepot | where buffer is a plain pointer |
| 16:31:42 | coffeepot | then it can be used like an array: for idx in 0..<count: result.add(sbuf[idx]) |
| 16:32:18 | * | zepolen quit (Read error: Connection reset by peer) |
| 16:32:35 | krux02 | coffeepot: thanks a lot, I will introduce it in my codebase |
| 16:32:54 | krux02 | even though my code definitively works |
| 16:33:18 | coffeepot | thanks relayed to filwit :) |
| 16:33:57 | coffeepot | it's great you got it working, but it'll be easier to work with using unchecked arrays |
| 16:34:10 | * | junw_ quit (Ping timeout: 240 seconds) |
| 16:34:12 | filwit | oh wasn't paying attention, looks like coffeepot showed you... I'll finish my gist for future reference I support |
| 16:34:54 | * | zepolen joined #nim |
| 16:34:57 | coffeepot | it's probably easier to read in a gist to be fair |
| 16:35:17 | * | junw_ joined #nim |
| 16:36:38 | filwit | https://gist.github.com/PhilipWitte/b4c8188287175cf99338 |
| 16:36:45 | filwit | untested |
| 16:37:29 | filwit | whoops.. see there's bug in the top version (didn't dereference the 'ptr int').. but it's way harder to catch |
| 16:37:58 | filwit | fixed |
| 16:39:11 | * | arnetheduck quit (Ping timeout: 264 seconds) |
| 16:43:20 | * | endragor_ joined #nim |
| 16:44:54 | * | zepolen quit () |
| 16:45:30 | coffeepot | Here's my gist too that shows how you can use unchecked arrays to treat the same buffer as different typed (and type checked) arrays: https://gist.github.com/coffeepots/fe582c473aa3c9b64f4f |
| 16:45:59 | coffeepot | really handy when working with C where you get a pointer and maybe a type id but you want to use Nim's strong typing |
| 16:46:15 | * | endragor quit (Ping timeout: 240 seconds) |
| 16:46:49 | filwit | heh yeah, that's a pretty cool trick too |
| 16:46:51 | coffeepot | uh, where it says utf16 in the comment... ignore that, I meant int :) |
| 16:47:26 | * | endragor_ quit (Ping timeout: 240 seconds) |
| 16:50:11 | coffeepot | yeah it was also really handy when I was fetching widechar strings into a buffer and being able to echo out the array buffer as bytes, chars, ints, or utf16! :D |
| 16:50:19 | coffeepot | for debugging I mean |
| 16:51:20 | filwit | i just really like the ability to declare a C-Wrapper which is more descriptive than the actual C code, lol |
| 16:52:14 | coffeepot | yes definitely, at first I was in cast hell till I was told about this. Suddenly writing for C becomes pretty much normal Nim :) |
| 16:52:30 | filwit | using CArray[] tells you what's going on with the memory, and governs how you access it.. using C/C++ directly you have to read the docs to be sure |
| 16:53:25 | filwit | yeah same... I was having trouble debugging my Assimp wrapper until I switched over to CArray.. then my life became so much easier |
| 16:53:58 | coffeepot | yeah and as it's type checked you don't have to worry about a lot of common errors that'd happen with pointers. Although still room for errors reading past the end of the buffer, but l'm sure it'd be simple to handle that too with a bit of thought |
| 16:54:51 | coffeepot | handle it as in wrap the length properly. Maybe it'd be worth writing an actual C array wrapper that handles it all in a neat package |
| 16:54:57 | coffeepot | it'd be tiny though! |
| 16:56:16 | filwit | yes, about that: in your wrapper you can simply not expose the array directly, and make an access function which asserts bounds checking (against the structures other size property, etc)... which means you can make zero-overhead (in release) C wrappers in Nim which are pretty very safe |
| 16:56:47 | filwit | eh.. you just said pretty much the same thing, whoops |
| 16:56:54 | * | filcuc quit (Read error: Connection reset by peer) |
| 16:57:17 | filwit | but yeah, that's my plan for the 2 wrappers I have (don't currently do that though) |
| 17:00:18 | coffeepot | maybe we could have a c interop module with handy stuff like this |
| 17:00:34 | coffeepot | i'd be interested in such a wrapper, just to code prettify! |
| 17:01:08 | * | Varriount quit (Disconnected by services) |
| 17:01:08 | * | Varriount_ joined #nim |
| 17:01:28 | filwit | yeah, IMO (and this was brought up the other day on #nim) the unsafe features of system.nim (alloc/free/etc) should be split into an 'unsafe.nim' where you could also add types/utilities like that |
| 17:02:01 | filwit | Araq said nobody liked it when unsigned was split, but I think that's a completely different situation |
| 17:02:07 | coffeepot | hmm interesting |
| 17:02:41 | coffeepot | personally I wouldn't have a problem with that, as when I'm doing alloc0 et al I'll probably want to use lots of unsafe stuff |
| 17:03:17 | filwit | moving unsafe features out of system make it more clear what was unsafe, and allow for people to use the 'from unsafe import nil' thing to enforce the use of 'unsafe.whatever' throughout a module |
| 17:03:34 | krux02 | Araq also said once, that unsafe in another language that I do not remember resulted in theat basically every module imported unsafe in the beginning and because of that he is not too much of a fan of an unsafe package |
| 17:04:20 | filwit | i don't see how that could possibly be the case.. the majority of your code does not rely on the unsafe features of system.nim... not directly at least. |
| 17:05:24 | filwit | besides.. the naming stuff with the unsafe features needs to be unified anyways... we have 'createU' for uninitialized memory, but then 'alloc0' instead of 'allocU' |
| 17:05:26 | krux02 | by the way, what is the easiest way to share procs between two types, that do not use ref types? |
| 17:05:59 | coffeepot | krux02: just use a bar to separate them |
| 17:06:08 | coffeepot | proc a(int | bool) = |
| 17:06:24 | krux02 | coffeepot, that seems to be fair |
| 17:06:28 | krux02 | thanks a lot |
| 17:06:33 | coffeepot | proc a(val: int | bool) = |
| 17:06:38 | coffeepot | np :) |
| 17:06:56 | krux02 | can I also do type Foobar = int | bool? |
| 17:07:04 | filwit | yes |
| 17:07:10 | filwit | it creates a type class |
| 17:07:13 | krux02 | thanks a lot |
| 17:07:15 | coffeepot | personally I think | is just the best thing since sliced bread :3 But I think this is just the simplest form of concept? |
| 17:07:30 | filwit | yes |
| 17:07:39 | krux02 | it is a very restricted form of concept, but I like it |
| 17:08:28 | filwit | the A|B syntax existed before the 'concept' allowed for more fine-grained type-class definitions |
| 17:08:30 | coffeepot | lol, one of the access procs I use looks like this: |
| 17:08:32 | coffeepot | proc `[]=`*(params: var SQLParams, index: string, data: int|int64|string|bool|float|Time|SQLBinaryData) = |
| 17:08:46 | coffeepot | o_O |
| 17:08:48 | filwit | nice |
| 17:11:45 | coffeepot | failed my times PR again :( |
| 17:12:00 | coffeepot | probably timezone related on the assert checks... |
| 17:12:47 | coffeepot | ah well, for tomorrow. |
| 17:12:50 | coffeepot | goodnight everyone :) |
| 17:13:33 | filwit | later |
| 17:14:00 | * | jaco60 quit (Remote host closed the connection) |
| 17:15:03 | Arrrr | good night little pot |
| 17:15:44 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:16:34 | * | jaco60 joined #nim |
| 17:23:00 | * | Arrrr quit (Ping timeout: 250 seconds) |
| 17:23:02 | krux02 | I have a question for the | syntax |
| 17:24:09 | krux02 | how does it compile? does it precompile all alternatives, or does it work like c++ templates, with lazy initialization? |
| 17:25:17 | krux02 | I fear that it might compile like c++ templates which in the end results in very slow compilations, because all mathods that are generic need to be recompiled in every module |
| 17:32:50 | def- | krux02: in general, you can compile with -d:release and look at the resulting C code, easy way to gain insights into how it's implemented |
| 17:35:56 | * | endragor joined #nim |
| 17:36:00 | filwit | krux02: it's a generic specialization, so yes it works like C++ templates... but remember, Nim's meta-programming features evaluate much faster than C++'s and it produces pure C code, so the performance impact is not comparable |
| 17:37:59 | filwit | krux02: to be clear, if you have ``foo(x:int|string)`` and you only use ``foo(123)`` then only a version for `int` is built (and all future use of `int` with `foo` refer to that).. |
| 17:40:10 | * | krux02 quit (Ping timeout: 260 seconds) |
| 17:40:47 | filwit | krux02: Nim's generics procs probably don't need to re-evaluate for every call if that specific version has already been built.. however Nim's `template` might (IDK about that either).. C++ is slow here because of how it includes code I think |
| 17:42:36 | filwit | C++ can't know what has already been built in some other source file (well.. maybe modern C++ compilers can know, IDK).. so it probably has to do much more work.. |
| 17:42:53 | filwit | that said, I don't know much about how the compiler really works here, so don't take my word for it |
| 17:43:39 | * | endragor quit (Remote host closed the connection) |
| 17:43:50 | filwit | but even if heavy macro/template use in my code (which very well might need to re-eval for every call) my compile times are still only 1-3 seconds |
| 17:44:02 | filwit | even with* |
| 17:46:29 | * | endragor joined #nim |
| 17:52:10 | * | toaoMgeorge joined #nim |
| 17:58:23 | * | brson joined #nim |
| 18:01:12 | * | toaoMgeorge quit (Read error: Connection reset by peer) |
| 18:07:35 | * | yglukhov joined #nim |
| 18:11:48 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 18:15:53 | * | yglukhov joined #nim |
| 18:26:32 | Araq | yglukhov: meh, maybe if you give it a better name |
| 18:26:55 | Araq | or even better let's use the existing --define mechanism for it |
| 18:27:19 | Araq | when defined(foo, "value1") |
| 18:29:39 | * | Dildosan joined #nim |
| 18:32:43 | yglukhov | Araq: err, how do i get the value if i dont know what to expect? |
| 18:33:37 | Araq | hmm good question |
| 18:34:01 | yglukhov | well, actually, nevermind really. beavause staticExec("echo $myvar") works smoothly =) |
| 18:34:01 | * | toaoMgeorge joined #nim |
| 18:34:25 | Araq | no, use getEnv in a 'static' block instead |
| 18:34:33 | yglukhov | what about js? |
| 18:34:38 | Araq | your way doesn't work on windows |
| 18:35:03 | yglukhov | yes it does with when defined(windows): staticExec("echo %myvar%") |
| 18:35:04 | yglukhov | =) |
| 18:36:02 | yglukhov | ah, but js doesnt define windows... |
| 18:36:21 | Araq | since I hate environment vars I shall give you system.definedValue |
| 18:36:40 | yglukhov | yay! thats a small victory! :DD |
| 18:37:24 | Araq | now somebody needs to fix my gc:v2 ... |
| 18:37:51 | Araq | but oh well, I'll give you guys your "heap dump" tool |
| 18:38:05 | Araq | cannot hurt to find my own bugs, right? |
| 18:38:27 | Araq | any graph format that should be produced? |
| 18:38:36 | yglukhov | err.. youre not addressing this to me, right? |
| 18:39:07 | Araq | I do |
| 18:39:37 | Araq | problem is that Graphviz doesn't scale |
| 18:40:07 | Araq | so what else could we use to produce nice output of the heap topology? |
| 18:40:25 | yglukhov | im not sure im following you. i guess i missed some discussion here... |
| 18:41:34 | Araq | well I'm working on gc:v2 which is the next generation of the GC, fixing the cycle collection and giving it realtime capabilities |
| 18:41:39 | Araq | but it keeps crashing |
| 18:42:15 | Araq | so I am thinking about a system.visualizeHeap() proc to help me in debugging |
| 18:42:33 | Araq | but this is generally useful for everybody to find leaks |
| 18:42:46 | filwit | Araq, mind giving me a quick explanation on how you deal with memory mutations on the graph you're checking for cycles incrementally? |
| 18:42:52 | Araq | the Heap usually has millions of objects though |
| 18:43:00 | * | derka quit (Quit: derka) |
| 18:43:10 | Araq | so I wonder how to output this thing |
| 18:43:31 | Araq | best would be a tool like graphviz that doesn't fail when the graph is really big |
| 18:43:52 | Araq | filwit: it's called "tri-color invariant", look it up please |
| 18:43:59 | filwit | k, thanks |
| 18:44:25 | filwit | oh.. i saw some other GC docs (Lua I think) referencing color something and was completely lost.. |
| 18:44:40 | yglukhov | does the problem occur with cyclic types only? if yes, there should be much less of such.. |
| 18:45:24 | filwit | yglukhov: it has to be, the ref-counting part of the existing GC is already realtime |
| 18:45:36 | filwit | only the cyclic scanning is not |
| 18:45:50 | def- | Araq: you can make graphviz worse at layout and get better performance in return |
| 18:46:27 | def- | like here for example: http://stackoverflow.com/questions/10766100/graphviz-dot-very-long-duration-of-generation |
| 18:47:37 | Araq | def-: it's not just the renderering speed, it also produces images. and image viewers suck, I prefer some tool that can navigate me through the graph |
| 18:48:03 | ldlework | Why is my friend getting, c:\users\jon\.nimble\pkgs\perlin-0.3.0\private\simplex.nim(10, 19) Error: cannot 'importc' variable at compile time |
| 18:48:09 | ldlework | When using this module works fine for me? |
| 18:48:24 | def- | Araq: hm, i wrote a tool for that in haskell once, but python is probably more usable: https://github.com/jrfonseca/xdot.py |
| 18:49:16 | Araq | ldlework: because his installation misses some files |
| 18:49:18 | Araq | perhaps. |
| 18:49:34 | Araq | what about this: https://gephi.org/ ? |
| 18:49:42 | def- | apart from that there are many more interactive viewers, but I've used none of them: http://www.graphviz.org/content/resources |
| 18:50:51 | Araq | ok, so .dot seems to be a good format |
| 18:50:56 | Araq | right? |
| 18:51:04 | Araq | gotta go, bbl |
| 18:52:03 | * | mikolalysenko left #nim (#nim) |
| 18:53:09 | def- | it's at least a very common format for graphs. for really big graphs i've seen simple lists of adjacent nodes |
| 18:57:07 | * | Matthias247 joined #nim |
| 19:03:55 | * | jsudlow joined #nim |
| 19:06:33 | * | yglukhov quit (Remote host closed the connection) |
| 19:13:39 | * | derka joined #nim |
| 19:13:53 | * | derka quit (Client Quit) |
| 19:16:10 | * | Senketsu quit (Quit: Leaving) |
| 19:28:42 | * | vendethiel joined #nim |
| 19:31:37 | * | derka joined #nim |
| 19:32:22 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:37:11 | * | Senketsu joined #nim |
| 19:42:03 | jsudlow | Hey @all... been trying to run the perlin example on .13 for windows and get the following https://gist.github.com/jsudlow/0d18514af15603b4d9ad do you guys think I need some more files that aren't part of the windows build yet? |
| 19:42:42 | * | junw_ quit (Ping timeout: 256 seconds) |
| 19:51:01 | * | endragor quit (Remote host closed the connection) |
| 19:53:27 | def- | jsudlow: looks like the perlin module just has a bug |
| 19:53:44 | * | derka quit (Read error: Connection reset by peer) |
| 19:57:46 | * | derka joined #nim |
| 19:58:00 | def- | jsudlow: ah, try to use the HEAD version of perlin |
| 19:58:31 | def- | jsudlow: it's fixed there: nimble install "perlin@#head" |
| 20:00:16 | jsudlow | def: ahh I see thx def |
| 20:00:19 | jsudlow | i'll give it a shot! |
| 20:00:36 | gokr | Araq: When you are back I am desperate for some c2nim wisdom - I am so close, but it just doesn't work. |
| 20:00:38 | def- | i also filed an issue at the perlin repo to have a new release, easier that way |
| 20:01:15 | * | saml quit (Ping timeout: 240 seconds) |
| 20:02:38 | jsudlow | def that worked! I can now get the output from the noise function. You guys are good |
| 20:06:32 | * | nsf quit (Quit: WeeChat 1.4) |
| 20:08:57 | ldlework | jsudlow: nice! |
| 20:11:31 | * | saml joined #nim |
| 20:12:57 | * | yglukhov joined #nim |
| 20:29:04 | * | tinAndi joined #nim |
| 20:48:19 | * | derka quit (Quit: derka) |
| 21:09:02 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 21:14:11 | * | irrequietus joined #nim |
| 21:16:11 | * | derka joined #nim |
| 21:18:35 | * | Dildosan quit (Quit: Leaving) |
| 21:20:41 | * | desophos joined #nim |
| 21:21:54 | * | mat4 joined #nim |
| 21:21:58 | mat4 | hello |
| 21:24:51 | * | JStoker quit (Quit: JStoker is gone :() |
| 21:25:23 | * | JStoker joined #nim |
| 21:25:36 | gokr | mat4: heya |
| 21:25:45 | mat4 | hi gokr |
| 21:26:25 | gokr | I have a blinking nRF52 dev board on my chest here. Not Nim yet though, just the regular blinky. |
| 21:29:23 | mat4 | doe you mean the one from Nordic Semiconductor ? |
| 21:29:27 | gokr | yeah |
| 21:30:26 | gokr | I gotta say, these companies are not that structured when it comes to SDKs, downloads, instructions etc. So easy to get completely lost. |
| 21:31:01 | gokr | For example, an SDK ought to be complete IMHO. Having to download 3-4 pieces from different places sucks. |
| 21:33:19 | mat4 | I agree, however this is sadly not uncommon |
| 21:35:18 | * | mischa-masha joined #nim |
| 21:36:35 | mat4 | the nRF52832 SoC seem to be easy programmable in assembler by the way |
| 21:38:37 | * | JStoker quit (Quit: JStoker is gone :() |
| 21:39:08 | * | JStoker joined #nim |
| 21:42:54 | * | idan_ joined #nim |
| 21:49:22 | gokr | mat4: It looks quite impressive on paper. |
| 21:54:59 | mat4 | looks good for auto controlling your home :) |
| 22:02:35 | * | brson quit (Ping timeout: 240 seconds) |
| 22:03:30 | mat4 | with a smartfone |
| 22:03:50 | mat4 | ^smartphone |
| 22:03:54 | * | tinAndi quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]) |
| 22:10:41 | * | brson joined #nim |
| 22:18:26 | * | nsf joined #nim |
| 22:21:30 | * | mat4 quit (Quit: Verlassend) |
| 22:23:27 | * | BlaXpirit quit (Quit: Bye) |
| 22:23:42 | * | BlaXpirit joined #nim |
| 22:24:48 | * | idan_ quit (Remote host closed the connection) |
| 22:25:14 | * | Trustable quit (Remote host closed the connection) |
| 22:29:17 | * | Matthias247 joined #nim |
| 22:33:21 | * | FreezerburnV joined #nim |
| 22:34:05 | * | mischa-masha quit (Quit: Page closed) |
| 22:41:21 | * | junw joined #nim |
| 22:44:40 | * | allan0 quit (Ping timeout: 245 seconds) |
| 22:45:26 | * | allan0 joined #nim |
| 22:47:05 | * | Demon_Fox joined #nim |
| 22:49:39 | Araq | gokr: I'm here |
| 23:01:14 | * | irrequietus quit () |
| 23:01:14 | * | yglukhov quit (Read error: Connection reset by peer) |
| 23:01:49 | * | yglukhov joined #nim |
| 23:04:09 | * | yglukhov_ joined #nim |
| 23:04:09 | * | yglukhov quit (Read error: Connection reset by peer) |
| 23:17:46 | gokr | Araq: I kinda ran out of steam with c2nim. |
| 23:20:57 | Araq | yes? |
| 23:21:23 | gokr | I manage to compile and link "blinky" (blinks a led) - it seems to be just fine (nm report no unresolved names etc) |
| 23:21:38 | gokr | But it just will not run. I am compiling via cpp here, since Arduino libs are cpp. |
| 23:21:59 | gokr | If I replace the generated blink.cpp with a handwritten original blink.cpp - then it works. |
| 23:22:22 | gokr | And staring at these two files doesn't make me wiser. |
| 23:22:23 | * | mnemonikk joined #nim |
| 23:22:23 | * | mnemonikk quit (Changing host) |
| 23:22:23 | * | mnemonikk joined #nim |
| 23:22:29 | Araq | gist them |
| 23:22:35 | gokr | give me a min |
| 23:24:01 | * | gour quit (Quit: WeeChat 1.4) |
| 23:29:12 | * | ludocode quit (Ping timeout: 250 seconds) |
| 23:31:06 | * | junw_ joined #nim |
| 23:31:58 | * | ludocode joined #nim |
| 23:33:15 | * | derka quit (Quit: derka) |
| 23:34:50 | * | junw quit (Ping timeout: 260 seconds) |
| 23:38:50 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 23:43:10 | * | lompik joined #nim |
| 23:43:23 | * | ludocode quit (Ping timeout: 264 seconds) |
| 23:44:04 | * | derka joined #nim |
| 23:46:41 | * | ludocode joined #nim |
| 23:47:46 | * | vendethiel joined #nim |
| 23:52:30 | * | yglukhov_ quit (Remote host closed the connection) |
| 23:54:25 | * | derka quit (Ping timeout: 240 seconds) |
| 23:57:56 | * | yglukhov joined #nim |
| 23:59:11 | * | derka joined #nim |