| 00:06:36 | * | Dildosan quit (Quit: Leaving) |
| 00:08:28 | gokr | Araq: Using the nep1 - but... why is "#define VM_NORMAL_START_MRE_ENV 1" translated to "const VM_NORMAL_START_MRE_ENV* = 1" ? |
| 00:08:50 | gokr | Doesn't mangling do macros? |
| 00:09:42 | ThePythonicCow | When dealing with ring buffers using arithmetic modulo the buffer size, I =expect= to have to explicitly check for wrap around when doing add/subtract. Sometimes C makes it easy for me to hide that detail with its handling of unsigned, if my buffer size is 8, 16 or 32 bits, but that may be a curse (laying a trap for someone maintaining my code) more than a blessing |
| 00:10:29 | Araq | gokr: nep1 says consts may stay ALL_UPPER_CASE |
| 00:10:35 | Araq | iirc |
| 00:10:55 | gokr | It seems... it sometimes changes it. |
| 00:11:03 | * | vendethiel joined #nim |
| 00:19:26 | * | brson quit (Ping timeout: 240 seconds) |
| 00:25:39 | * | brson joined #nim |
| 00:32:35 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 00:48:26 | toaoMgeorge | Stupid question: how do you actually use concepts? In the manual you can see how they are defined but not used... I assumed it was something like proc foo(x: Concept), but my simple example didn't compile |
| 00:48:38 | toaoMgeorge | The code was: |
| 00:49:41 | toaoMgeorge | The Container[T] concept from the manual |
| 00:51:02 | toaoMgeorge | Something like proc Foo(x: Container[int]) = for item in x: echo item |
| 00:52:24 | toaoMgeorge | And I passed to that proc a seq[int] |
| 00:54:21 | toaoMgeorge | The compiler told me that the expected type was Container[int] and not seq[int], so I don't know, maybe the problem is the syntax... |
| 00:55:53 | * | filwit quit (Read error: Connection reset by peer) |
| 00:56:21 | * | filwit joined #nim |
| 00:57:13 | filwit | toaoMgeorge: Here's a example of how to use Concepts in Nim: https://gist.github.com/PhilipWitte/33819b40112a18c30b43 |
| 00:58:32 | def- | toaoMgeorge: works for me: https://gist.github.com/def-/810ac9c2ee582a94f81b |
| 00:59:35 | toaoMgeorge | Mmh |
| 00:59:39 | toaoMgeorge | Strange |
| 01:01:20 | toaoMgeorge | I really don't know what was wrong... |
| 01:04:06 | Araq | def-: we already have nimfix for nimfmt but somebody needs to polish it |
| 01:04:41 | toaoMgeorge | I'll try again tomorrow... meanwhile I'm really appreciating how Nim feels, congrats to the developers... |
| 01:10:07 | * | toaoMgeorge quit (Quit: Bye) |
| 01:37:26 | * | gokr quit (Ping timeout: 250 seconds) |
| 01:38:32 | * | gokr joined #nim |
| 01:42:48 | * | gokr quit (Ping timeout: 252 seconds) |
| 02:09:52 | ldlework | I need to try to swallow the whole "give each method you want callable from subclasses two distinct names" thing. |
| 02:10:02 | ldlework | But it tastes bad. |
| 02:13:52 | ldlework | I think because it basically doesn't use any of the runtime method system at all and puts it on the programmer to just duplicate the name for the method so that subclasses can call it but that doesn't really have anything to do with methods per se. |
| 02:15:01 | ldlework | I don't really want to use a macro for all my types just incase someone wants to subclass it and reuse code |
| 02:15:31 | * | zaquest quit (*.net *.split) |
| 02:15:34 | ldlework | And the dual method thing is bad since as soon as you want to call a baseclass method you have to go back and refactor the baseclass to support that. |
| 02:17:55 | * | brson quit (Ping timeout: 240 seconds) |
| 02:22:09 | * | zaquest joined #nim |
| 02:23:58 | * | endragor joined #nim |
| 02:24:58 | Xe | does Nim have a splat operator? |
| 02:30:29 | federico3 | Splat? |
| 02:33:42 | * | filwit quit (Quit: Leaving) |
| 02:38:10 | * | francisl joined #nim |
| 02:45:37 | * | vendethiel joined #nim |
| 02:46:48 | ldlework | /home/dlacewell/nim/dadren/dadren/generators.nim(46, 35) Error: type mismatch: got (Generator, (int, int)) |
| 02:46:50 | ldlework | but expected one of: |
| 02:46:52 | ldlework | generators.makeTile(self: StaticGenerator, pos: Point) |
| 02:47:15 | ldlework | StaticGenerator is "ref object of Generator" and Point is "tuple[int, int]" |
| 02:47:29 | ldlework | The Nim compiler hates me so bad today :( |
| 02:47:47 | * | ldlework sighs and gives up. |
| 02:49:41 | ldlework | I just want to make reusable factories :( https://gist.github.com/dustinlacewell/4f7184e75b23a42e9426 |
| 02:49:42 | * | francisl quit (Quit: francisl) |
| 02:56:21 | * | skyfex joined #nim |
| 02:56:56 | Varriount | Xe: The splat operator should be fairly easy to do with a macro. |
| 03:05:22 | ldlework | /topic It should be fairly easy with a macro. |
| 03:05:27 | ldlework | :) |
| 03:06:30 | * | skyfex quit (*.net *.split) |
| 03:09:38 | * | francisl joined #nim |
| 03:09:42 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 03:10:46 | * | endragor quit (Remote host closed the connection) |
| 03:40:56 | * | ephja quit (Ping timeout: 250 seconds) |
| 04:11:43 | * | endragor joined #nim |
| 04:17:38 | Varriount | ThePythonicCow: NimLime issue is fixed. |
| 04:24:00 | ThePythonicCow | ah - the colon : path separator on Linux - thanks! |
| 04:24:30 | * | endragor quit (Remote host closed the connection) |
| 04:28:11 | * | endragor joined #nim |
| 04:32:14 | Varriount | ThePythonicCow: Oddly enough, there's no way to escape the colon separator in a Linux path variable. |
| 04:33:08 | Varriount | ThePythonicCow: Also, you may want to update again, as I forgot to test the fix and broke package loading. |
| 04:34:11 | ThePythonicCow | ah - I was just having package upgrade problems - will try again - no way to know yet if that was your just fixed breakage, or my own drain bamage |
| 04:38:16 | Varriount | ThePythonicCow: Well, it prevented the plugin from initializing completely. I accidentally created a circular dependancy between two modules. |
| 04:39:01 | ThePythonicCow | Varriount: Your Github Installation instructions state "Enter the project's URL (no .git extension!)" ... exactly what URL should I be adding ... perhaps those Instructions could state this, literally ? |
| 04:39:26 | Varriount | There are installation instructions? |
| 04:39:39 | ThePythonicCow | I don't use Sublime Package stuff much, and easily go off the rails |
| 04:39:45 | ThePythonicCow | Yes -- see https://github.com/Varriount/NimLime/blob/master/README.md |
| 04:40:05 | Varriount | https://github.com/Varriount/NimLime |
| 04:40:22 | Varriount | I think that's it. |
| 04:40:57 | Varriount | ThePythonicCow: I don't think I wrote that, but if it works it works. |
| 04:41:06 | ThePythonicCow | ok - that wasn't working for me ... but lord only knows |
| 04:41:45 | Varriount | ThePythonicCow: Although, I really recommend going through package control. It should use the latest tag automatically, IIRC |
| 04:42:53 | Varriount | Yeah, it's set to use the repository's tags as signals to update. |
| 04:43:33 | Varriount | I can't promise that the master branch won't be completely broken at certain points either. |
| 04:43:57 | ThePythonicCow | I can't get that far -- just removed that Repository link, uninstalled NimLime, stopped and restarted Sublime3, added that github link you just gave above as a Sublime3 Repository, and now I cannot Install that NimLime Package - no such package is available to install |
| 04:46:00 | ThePythonicCow | aha - that's because I already had NimLime installed (so it was not listed to install again). |
| 04:46:24 | ThePythonicCow | I didn't realize I had NimLime installed in Sublime3 because I was no longer getting the $PATH parsing error popups (cool!) |
| 04:46:43 | Varriount | ThePythonicCow: Package Control auto-upgrades packages. |
| 04:47:15 | Varriount | ThePythonicCow: By the way, what did you mean by "popups"? |
| 04:47:41 | ThePythonicCow | "auto-upgrade" cool - and if something gets broken - well if I didn't like dealing with computer breakage, I would have lived a very different life. |
| 04:47:47 | ThePythonicCow | By popups I mean: |
| 04:48:32 | ThePythonicCow | The $PATH : versus ; problem was causing me to see about four popups complaining that the NimLime python code in the Sublime3 package could not find Nim nor Nimsuggest |
| 04:48:53 | Varriount | Ah, good to know it's working. |
| 04:49:34 | Varriount | I'm probably going to opt in for a less-annoying popup for the nimble (and possibly nimsuggest) executables, since those aren't needed as much. |
| 04:49:36 | ThePythonicCow | (An strace showed that Sublime was looking for "/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin/nim", all one string, on the open call ... |
| 04:50:22 | ThePythonicCow | Yup - we're good now - I will start using NimLime and hopefully my life will be a wee bit better :) |
| 04:50:55 | Varriount | ThePythonicCow: If you're using the Nimsuggest commands, keep in mind that errors may be due to Nimsuggest, not necessarily the plugin. |
| 04:51:49 | Varriount | Also, let me know if terminal/shell windows pop-up when running any commands. I think I fixed that, but I only know for certain under windows. |
| 04:52:22 | ThePythonicCow | ok |
| 05:03:54 | * | darkf_ joined #nim |
| 05:04:13 | Varriount | Hey darkf_ |
| 05:05:25 | darkf_ | hello Varriount |
| 05:07:35 | * | darkf quit (Ping timeout: 260 seconds) |
| 05:09:03 | * | Regex_ joined #nim |
| 05:09:25 | * | Regex_ left #nim ("Leaving") |
| 05:11:28 | * | francisl quit (Quit: francisl) |
| 05:14:29 | * | brson joined #nim |
| 05:21:16 | * | darkf_ is now known as darkf |
| 05:22:26 | * | lompik quit (Ping timeout: 252 seconds) |
| 05:40:47 | * | s4 joined #nim |
| 05:50:55 | * | endragor quit (Remote host closed the connection) |
| 05:54:15 | * | endragor joined #nim |
| 06:25:28 | * | s4 quit (Quit: Konversation terminated!) |
| 06:27:31 | * | endragor quit (Remote host closed the connection) |
| 06:28:43 | * | s4 joined #nim |
| 06:30:29 | * | endragor joined #nim |
| 06:33:51 | * | Varriount quit (Disconnected by services) |
| 06:33:52 | * | Varriount_ joined #nim |
| 06:37:28 | * | z4pn joined #nim |
| 06:37:32 | * | z4pn left #nim (#nim) |
| 06:44:26 | * | brson quit (Ping timeout: 240 seconds) |
| 07:16:46 | * | baff1e joined #nim |
| 07:17:40 | * | warkid joined #nim |
| 07:24:13 | * | endragor quit (Remote host closed the connection) |
| 07:38:17 | * | Senketsu joined #nim |
| 07:50:32 | * | gour_ joined #nim |
| 07:51:04 | * | endragor joined #nim |
| 08:02:51 | * | Trustable joined #nim |
| 08:11:10 | * | Arrrr joined #nim |
| 08:13:00 | * | desophos quit (Read error: Connection reset by peer) |
| 08:18:35 | * | toaoMgeorge joined #nim |
| 08:21:15 | * | warkid quit (Ping timeout: 252 seconds) |
| 08:24:56 | * | toaoMgeorge quit (Ping timeout: 245 seconds) |
| 08:25:15 | * | Demon_Fox quit (Quit: Leaving) |
| 08:35:13 | * | jaco60 joined #nim |
| 08:38:04 | * | warkid joined #nim |
| 08:39:42 | * | jaco60 quit (Ping timeout: 252 seconds) |
| 08:45:48 | * | apotheon_ joined #nim |
| 08:46:42 | gour_ | Araq: it is said that one of the influences on Nim's design is Lisp, so just wonder if you did use some concrete implementation(s) or design is influenced purely by Lisp's general concept? |
| 08:52:30 | * | apotheon quit (*.net *.split) |
| 09:03:13 | * | gokr joined #nim |
| 09:12:23 | * | derka joined #nim |
| 09:17:50 | Araq | gour_: the macro system |
| 09:20:14 | gour_ | Araq: thanks |
| 09:20:20 | * | gour_ is now known as gour |
| 09:23:56 | * | darkf quit (Quit: Leaving) |
| 09:28:36 | * | coffeepot joined #nim |
| 09:30:05 | * | brson joined #nim |
| 09:30:23 | * | brson quit (Read error: Connection reset by peer) |
| 09:35:47 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 09:39:54 | * | warkid quit (Ping timeout: 252 seconds) |
| 09:45:59 | * | coffeepot joined #nim |
| 09:46:28 | gokr | Araq: "Stream* {.importcpp: "Stream", header: "Stream.h".} = object of Print" leads to "Error: inheritance only works with non-final objects" |
| 09:47:50 | Araq | make Print .inheritable |
| 09:47:50 | * | gour quit (Read error: Connection reset by peer) |
| 09:48:07 | Araq | for c2nim you can use #inheritable Print |
| 09:48:12 | * | gour joined #nim |
| 09:54:53 | gokr | cool |
| 09:58:05 | * | derka_ joined #nim |
| 09:58:44 | gokr | Araq: I really wonder why the seemingly "incomplete" list of includes in blink.cpp |
| 09:59:02 | Araq | it only includes what is necessary |
| 09:59:03 | gokr | Why doesn't "import arduino" lead to "#include "Arduino.h" "? |
| 09:59:23 | gokr | Without it - I get link errors on setup/loop. |
| 09:59:30 | gokr | If I add it in manually, all links. |
| 09:59:32 | Araq | because you don't need anything from arduino that would require #include "Arduino.h" |
| 09:59:59 | gokr | Well, gcc thinks otherwise ;) |
| 10:00:06 | * | derka quit (Ping timeout: 250 seconds) |
| 10:00:07 | * | derka_ is now known as derka |
| 10:00:20 | gokr | The inheritable thing worked, thanks. |
| 10:00:51 | gokr | I also realized (duh) that I can instrument the generated cpp code with some Serial.println stuff - and perhaps I can then see what the hell goes wrong when running it. |
| 10:01:14 | gokr | But I still need to figure out why that include ... is needed for linking to succeed. |
| 10:01:29 | gokr | ok, later |
| 10:02:55 | Araq | perhaps it contains some #pragma linker bullshit |
| 10:25:55 | * | gour_ joined #nim |
| 10:26:59 | * | gour quit (Ping timeout: 276 seconds) |
| 10:31:13 | * | toaoMgeorge joined #nim |
| 10:33:08 | * | gour joined #nim |
| 10:34:59 | * | sepisoad joined #nim |
| 10:35:15 | * | sepisoad quit (Max SendQ exceeded) |
| 10:35:42 | * | sepisoad joined #nim |
| 10:35:58 | * | sepisoad quit (Max SendQ exceeded) |
| 10:36:06 | * | gour_ quit (Ping timeout: 272 seconds) |
| 10:36:10 | * | gour__ joined #nim |
| 10:36:31 | * | sepisoad joined #nim |
| 10:36:45 | * | sepisoad quit (Max SendQ exceeded) |
| 10:37:13 | * | sepisoad joined #nim |
| 10:37:26 | * | gour_ joined #nim |
| 10:37:29 | * | sepisoad quit (Max SendQ exceeded) |
| 10:38:01 | * | sepisoad joined #nim |
| 10:38:10 | * | gour quit (Ping timeout: 240 seconds) |
| 10:38:16 | * | gour_ is now known as gour |
| 10:38:17 | * | sepisoad quit (Max SendQ exceeded) |
| 10:41:17 | * | gour__ quit (Ping timeout: 276 seconds) |
| 10:42:17 | * | gour_ joined #nim |
| 10:43:02 | * | gour quit (Ping timeout: 256 seconds) |
| 10:50:16 | * | gour joined #nim |
| 10:52:59 | * | gour_ quit (Ping timeout: 276 seconds) |
| 10:54:41 | * | gour_ joined #nim |
| 10:56:53 | * | gour quit (Ping timeout: 276 seconds) |
| 11:01:19 | wuehlmaus | i like lisps way of e.g. adding values with prefix (+ 1 2 3 4 5 6). is something like that in nim somewhere? |
| 11:01:25 | * | gour joined #nim |
| 11:04:10 | * | gour_ quit (Ping timeout: 252 seconds) |
| 11:08:53 | vega_nsk | Hi to all! What can I use to introduce shared state between the threads? For now I create shared object in the main thread and then use ``ptr`` to it in the threads. |
| 11:11:12 | * | ka joined #nim |
| 11:11:34 | * | ka quit (Client Quit) |
| 11:11:52 | * | dmitry_p joined #nim |
| 11:14:00 | * | Salewski joined #nim |
| 11:15:08 | * | derka quit (Quit: derka) |
| 11:17:27 | Araq | vega_nsk: that works. |
| 11:17:41 | Araq | wuehlmaus: not really |
| 11:18:04 | Salewski | For module tables, there are default values mentioned, like getOrDefault(). For Ruby Hashes, we can set the default value when we create the hash. For Nim I am still not sure -- is default plain binary zero? No way to set it explicitly? |
| 11:18:56 | * | arnetheduck joined #nim |
| 11:18:56 | Araq | yep |
| 11:19:24 | Salewski | OK, thanks. |
| 11:19:31 | * | Salewski quit () |
| 11:21:32 | vega_nsk | Araq, thanks! |
| 11:21:54 | Araq | yay my graph has 43000 nodes and I don't see anything |
| 11:22:01 | Araq | time for sqlite I guess |
| 11:36:19 | * | Sembei joined #nim |
| 11:39:48 | * | ephja joined #nim |
| 11:49:05 | * | gokr left #nim (#nim) |
| 11:50:04 | * | derka joined #nim |
| 11:55:36 | * | dmitry_p quit (Quit: Leaving) |
| 12:15:57 | * | derka_ joined #nim |
| 12:17:08 | * | derka quit (Ping timeout: 248 seconds) |
| 12:17:08 | * | derka_ is now known as derka |
| 12:28:42 | * | toaoMgeorge quit (Ping timeout: 250 seconds) |
| 12:31:44 | * | toaoMgeorge joined #nim |
| 12:49:34 | * | vendethiel joined #nim |
| 12:53:13 | * | lompik joined #nim |
| 12:58:08 | * | BitPuffin joined #nim |
| 13:05:15 | * | gokr joined #nim |
| 13:10:30 | * | derka quit (Quit: derka) |
| 13:12:26 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 13:21:45 | * | derka joined #nim |
| 13:21:46 | * | toaoMgeorge quit (Ping timeout: 240 seconds) |
| 13:27:52 | * | jaco60 joined #nim |
| 13:29:24 | * | derka quit (Quit: derka) |
| 13:29:30 | * | toaoMgeorge joined #nim |
| 13:33:20 | * | jaco60 quit (Ping timeout: 260 seconds) |
| 13:33:46 | * | s4 quit (Quit: Konversation terminated!) |
| 13:46:00 | * | jaco60 joined #nim |
| 13:46:10 | * | arnetheduck quit (Ping timeout: 260 seconds) |
| 13:47:13 | * | arnetheduck joined #nim |
| 13:47:31 | * | vendethiel joined #nim |
| 13:57:22 | * | endragor_ joined #nim |
| 13:57:58 | * | toaoMgeorge quit (Ping timeout: 256 seconds) |
| 13:58:02 | Varriount_ | Araq: Object graph? |
| 13:58:09 | * | Varriount_ is now known as Varriount |
| 13:58:14 | Araq | yeah |
| 13:58:35 | Araq | but don't worry, I'm doing it differently |
| 13:58:59 | Araq | wrote a quick REPL to be able to analyse the graphs |
| 14:00:06 | * | endragor quit (Ping timeout: 240 seconds) |
| 14:01:35 | * | endragor_ quit (Ping timeout: 240 seconds) |
| 14:01:59 | coffeepot | "wrote a quick REPL" (!) a Nim REPL? |
| 14:02:39 | * | toaoMgeorge joined #nim |
| 14:03:29 | Araq | no, a tool to deal with the new object graphs the GC can produce |
| 14:09:42 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 14:11:10 | ics | Speaking of... I haven't been able to install nrepl (not really looked into it though) but does anyone here use it or are the fast compiles enough? |
| 14:11:55 | * | warkid joined #nim |
| 14:13:52 | * | M-Quora quit (Remote host closed the connection) |
| 14:15:27 | * | vendethiel joined #nim |
| 14:17:46 | * | toaoMgeorge quit (Ping timeout: 252 seconds) |
| 14:19:32 | * | Dildosan joined #nim |
| 14:20:19 | * | M-max joined #nim |
| 14:20:46 | * | nchambers is now known as DowntimeAbbey |
| 14:21:30 | * | DowntimeAbbey is now known as nchambers |
| 14:26:11 | Araq | ics: for me they definitely are good enough |
| 14:30:52 | coffeepot | ah ok fair enough :) |
| 14:31:24 | coffeepot | excited to hear about a new GC, any headline features or just an iterative change? |
| 14:34:40 | Araq | iterative changes plus some new mechanism to better support multi-threading |
| 14:36:29 | coffeepot | cool! Sounds great :D |
| 14:36:52 | * | vendethiel quit (Ping timeout: 248 seconds) |
| 14:37:55 | ics | Araq: good to hear |
| 14:37:59 | ics | I looked into Nim because I wanted something I could compile even on a low-low-end Chromebook and it's been all good there though all my stuff is tiny. |
| 14:38:23 | Araq | well ... if I ever get it to work, that is |
| 14:38:26 | ics | ...and GHC just wasn't happening there :) |
| 14:39:29 | coffeepot | multithreading without simple locking is pretty damn hard tbf |
| 14:41:33 | coffeepot | going for some kind of STM approach? |
| 14:43:47 | Araq | STM is worthless for a GC |
| 14:44:43 | coffeepot | ooop, fair enough. Curious to see what you come up with :) |
| 14:45:32 | coffeepot | ics: IIRC Nim caches already compiled files so it's pretty quick even on decent sized projects if you're just changing something hear and there |
| 14:46:51 | coffeepot | Araq: there have been several STMs made for GC languages though, although I'm assuming your definition of worthless != possible, of course ;) |
| 14:47:41 | coffeepot | not that I'm a fan of STM anyway to be honest |
| 14:48:21 | coffeepot | just, anything is better than locking... I seem to recall lockless data structures being on the GSoC list |
| 14:48:34 | ephja | did this ever work? "template lock(a: TLock; body: stmt) = pthread_mutex_lock(a) ..." |
| 14:49:32 | ephja | yes, I know about acquire, release and so on. neat solution |
| 14:50:44 | Araq | hmm? I have code using this template |
| 14:50:54 | Araq | it did work and continues to work |
| 14:51:47 | Araq | coffeepot: you can built STM on top of a GC, but for the GC itself it's worthless |
| 14:52:29 | coffeepot | Araq: ah of course, yes makes sense |
| 14:53:09 | Araq | I don't mind locking, the 'atomic' statement doesn't buy you all that much |
| 14:53:39 | * | toaoMgeorge joined #nim |
| 14:53:56 | Araq | and lockless data structures are just absurdly hard to work with. |
| 14:58:07 | coffeepot | tbh most of the time I just try to avoid locking by separating data in threads (partly why I really like the thread local GC in Nim), but it's harsh to see the performance hit if you need to lock a LOT, even with atomics. Think the atomics cause a pipeline stall don't they? |
| 14:58:49 | coffeepot | agreed though lockless algos aren't much better. Tried to write one once. Not clever enough XD |
| 14:59:05 | * | M-Quora joined #nim |
| 14:59:44 | coffeepot | Nim has the parallel construct though, don't see many people using it (including me, though I've not had to do any real threading yet) |
| 15:00:03 | * | vendethiel joined #nim |
| 15:00:18 | * | M-max quit (Quit: node-irc says goodbye) |
| 15:00:20 | coffeepot | so, curious to see what you come up with anyway :) |
| 15:04:37 | coffeepot | it would be amazing if the GC could share variables across threads and somehow stop multi write access |
| 15:04:51 | coffeepot | automatically i mean |
| 15:05:08 | ephja | Araq: it does expect a "ptr Pthread_mutex" |
| 15:05:37 | Araq | ephja: well I use it with Nim's acquire etc |
| 15:05:56 | Araq | the pthread stuff is just an example |
| 15:09:21 | gokr | Araq: Ran some tests now again. If I throw in the Arduino.h include - and also comment out the calls to systemInit000 and systemDatInit000 - then it works. |
| 15:09:54 | gokr | Funny enough, if I enable the call to systemDatInit000 it does NOT work, although... that function looks empty in the stdlib_system.cpp |
| 15:10:43 | ephja | Araq: so you're not using exactly that template? or you've defined a new type named Lock? |
| 15:10:51 | * | M-Quora quit (Remote host closed the connection) |
| 15:12:24 | Araq | ephja: checkout sharedtables.nim |
| 15:13:45 | * | warkid quit (Ping timeout: 252 seconds) |
| 15:14:31 | * | M-max joined #nim |
| 15:14:34 | * | arnetheduck quit (Ping timeout: 240 seconds) |
| 15:15:11 | ephja | so just a similar pattern then :p |
| 15:15:41 | ephja | that interface might be relevant to me |
| 15:18:48 | ephja | async file loading |
| 15:21:38 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 15:24:28 | * | toaoMgeorge quit (Quit: Bye) |
| 15:24:48 | * | toaoMgeorge joined #nim |
| 15:27:27 | coffeepot | BlaXpirit, are you there? |
| 15:27:38 | BlaXpirit | pong |
| 15:27:41 | coffeepot | :) |
| 15:27:48 | coffeepot | having trouble with your random module |
| 15:27:59 | coffeepot | import random gives me a linker error |
| 15:28:12 | coffeepot | c:\nimproj\misc\nimcache\random_util.o:random_util.c:(.text+0x185): undefined reference to `@__builtin_clzll@8' |
| 15:28:12 | BlaXpirit | okaay then |
| 15:28:22 | coffeepot | any ideas? |
| 15:28:43 | BlaXpirit | coffeepot, that may be something that's really worth fixing |
| 15:28:54 | BlaXpirit | or just something silly |
| 15:29:02 | BlaXpirit | but please give as much details as possible |
| 15:29:09 | coffeepot | sure :) |
| 15:29:20 | coffeepot | well I originally noticed the issue with the perlin module |
| 15:29:29 | coffeepot | but it seems to be in random |
| 15:29:47 | coffeepot | literally if I just go "import random" with nothing else it happens |
| 15:29:51 | coffeepot | here's the full linker issue: |
| 15:30:05 | coffeepot | CC: random_urandom |
| 15:30:05 | coffeepot | Hint: [Link] |
| 15:30:05 | coffeepot | c:\nimproj\misc\nimcache\random_util.o:random_util.c:(.text+0x185): undefined reference to `@__builtin_clzll@8' |
| 15:30:05 | coffeepot | Error: execution of an external program failed: 'gcc.exe -o c:\nimproj\misc\perlintest.exe c:\nimproj\misc\nimcache\random_urandom.o c:\nimproj\misc\nimcache\random_mt19937ar.o c:\nimproj\misc\nimcache\random_random_real.o c:\nimproj\misc\nimcache\random_util.o c:\nimproj\misc\nimcache\stdlib_math.o c:\nimproj\misc\nimcache\stdlib_etcpriv.o c:\n |
| 15:30:05 | coffeepot | improj\misc\nimcache\stdlib_hashes.o c:\nimproj\misc\nimcache\stdlib_intsets.o c:\nimproj\misc\nimcache\random_common.o c:\nimproj\misc\nimcache\stdlib_unsigned.o c:\nimproj\misc\nimcache\random_mersenne.o c:\nimproj\misc\nimcache\stdlib_macros.o c:\nimproj\misc\nimcache\stdlib_dynlib.o c:\nimproj\misc\nimcache\stdlib_winlean.o c:\nimproj\misc\nimc |
| 15:30:05 | coffeepot | ache\stdlib_parseutils.o c:\nimproj\misc\nimcache\stdlib_strutils.o c:\nimproj\misc\nimcache\stdlib_times.o c:\nimproj\misc\nimcache\random_random.o c:\nimproj\misc\nimcache\stdlib_system.o c:\nimproj\misc\nimcache\perlintest.o ' |
| 15:30:08 | BlaXpirit | wew |
| 15:30:28 | coffeepot | perlinetest.nim is just the line "import random" |
| 15:30:53 | BlaXpirit | use a pastebin. |
| 15:31:04 | BlaXpirit | please state compiler version |
| 15:31:36 | bbl_ | how about github issues ;) |
| 15:31:39 | coffeepot | tried clearing the nimcache folder, and just tried updating to the latest devel and still same error |
| 15:32:00 | coffeepot | i was just about to make a github issue but thought i'd ask here in case i did something silly |
| 15:32:17 | BlaXpirit | coffeepot, doesn't seem like something silly. the library uses a compiler-specific function |
| 15:32:38 | ephja | rarely do any official sources show up when googling the name of a module |
| 15:32:57 | BlaXpirit | when defined(gcc): use __builtin_clzll |
| 15:33:01 | BlaXpirit | that's what my lib does |
| 15:33:06 | * | toaoMgeorge quit (Ping timeout: 240 seconds) |
| 15:33:18 | BlaXpirit | i assumed that this is always available in gcc |
| 15:33:26 | BlaXpirit | just gotta figure out why your gcc is different |
| 15:33:28 | coffeepot | i'm on windows, if that makes a difference? |
| 15:33:40 | coffeepot | my gcc is from the 'download nim' package |
| 15:33:58 | BlaXpirit | uh anything could make a difference. download nim, eh? that means i'm gonna try it out |
| 15:34:23 | bbl_ | BlaXpirit: out of context but I must thank you for sfml bindings, nice work! |
| 15:35:19 | BlaXpirit | to clarify: I'm gonna try it out in 2 hours. not sure what you can do until then |
| 15:35:21 | coffeepot | steps to reproduce should be: download nim, install full package (including gcc of course), then I updated to the lasted devel nim (and copied the dist folder back in so it's the same gcc) |
| 15:35:54 | coffeepot | want me to make a github issue? |
| 15:36:18 | BlaXpirit | coffeepot, sure. |
| 15:36:27 | coffeepot | cool |
| 15:38:56 | BlaXpirit | that perlin library is so weird :o |
| 15:39:30 | BlaXpirit | requires my random module but uses only one tiny feature of it, and for other things it reinvents stuff or uses broken standard library |
| 15:39:58 | coffeepot | huh, well tbf I didn't look around much, was just glad that someone had implemented perlin in nim |
| 15:40:03 | coffeepot | it seemed pretty extensive |
| 15:41:50 | * | toaoMgeorge joined #nim |
| 15:41:59 | BlaXpirit | if nothing changed in that regard, then on windows the lib can generate only 32000 different combinations |
| 15:43:17 | * | vendethiel joined #nim |
| 15:45:29 | coffeepot | issue made |
| 15:45:42 | coffeepot | are you saying you could make a better perlin module? |
| 15:45:43 | coffeepot | :) |
| 15:47:16 | coffeepot | not sure if 32000 combinations is going to be an impediment for me or not. Just want a funky background in my sdl2 project :D |
| 15:47:35 | coffeepot | faster the better, of course |
| 15:47:46 | coffeepot | (I might want to animate it) |
| 15:51:11 | * | def- quit (Ping timeout: 245 seconds) |
| 15:53:15 | * | mrkishi quit (Ping timeout: 240 seconds) |
| 15:53:43 | * | M-Quora joined #nim |
| 15:53:56 | * | OnO quit (Ping timeout: 276 seconds) |
| 15:54:35 | * | dyce quit (Ping timeout: 276 seconds) |
| 15:54:41 | * | mal`` quit (Ping timeout: 272 seconds) |
| 15:55:10 | * | M-max quit (Quit: node-irc says goodbye) |
| 15:56:16 | * | def- joined #nim |
| 15:58:25 | * | OnO joined #nim |
| 16:01:24 | * | mrkishi joined #nim |
| 16:02:51 | * | dyce joined #nim |
| 16:07:23 | * | mal`` joined #nim |
| 16:07:24 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 16:18:46 | * | M-Quora quit (Remote host closed the connection) |
| 16:22:22 | * | M-max joined #nim |
| 16:23:07 | * | Dildosan quit (Quit: Leaving) |
| 16:25:21 | * | Sembei quit (Ping timeout: 245 seconds) |
| 16:37:26 | * | ics quit (Ping timeout: 250 seconds) |
| 16:37:52 | * | zielmicha quit (Ping timeout: 250 seconds) |
| 16:38:58 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:39:17 | * | zielmicha joined #nim |
| 16:40:19 | * | ics joined #nim |
| 16:49:43 | * | filwit joined #nim |
| 17:01:38 | * | M-Quora joined #nim |
| 17:02:30 | * | M-max quit (Quit: node-irc says goodbye) |
| 17:08:58 | * | nsf quit (Quit: WeeChat 1.4) |
| 17:15:23 | * | desophos joined #nim |
| 17:20:35 | * | toaoMgeorge quit (Ping timeout: 264 seconds) |
| 17:21:37 | Arrrr | Is it possible ... to iterate over some folders in compile time, read them, and include the content in a const array ? |
| 17:30:43 | Arrrr | ok ... is possible .. |
| 17:37:44 | * | toaoMgeorge joined #nim |
| 17:47:37 | Araq | Arrrr: indeed. since 0.13. |
| 18:17:15 | * | toaoMgeorge quit (Ping timeout: 240 seconds) |
| 18:24:38 | BlaXpirit | how do I detect if I'm using a 32-bit or 64-bit build of GCC? |
| 18:24:38 | * | toaoMgeorge joined #nim |
| 18:24:40 | * | nsf joined #nim |
| 18:25:50 | * | darkf joined #nim |
| 18:26:55 | * | yglukhov joined #nim |
| 18:28:19 | BlaXpirit | what I really want is to check availability of proc (n: culonglong): cint {.importc: "__builtin_clzll".} , and apparently the GCC shipped with 32-bit Nim for Windows doesn't have this |
| 18:29:25 | * | Matthias247 joined #nim |
| 18:31:00 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 18:35:26 | * | NhanH quit (Ping timeout: 240 seconds) |
| 18:36:56 | * | yglukhov joined #nim |
| 18:38:23 | * | NhanH joined #nim |
| 18:40:36 | * | pregressive joined #nim |
| 18:42:33 | Araq | BlaXpirit: you can only hack something with .emit or with staticExec |
| 18:43:20 | * | vendethiel joined #nim |
| 18:45:01 | BlaXpirit | is this about the checking availability part or is it really so difficult to detect GCC bit-ness? |
| 18:45:47 | * | pregressive quit (Ping timeout: 264 seconds) |
| 18:47:13 | * | pregressive joined #nim |
| 18:52:51 | * | irrequietus joined #nim |
| 18:54:04 | * | irrequietus quit (Read error: Connection reset by peer) |
| 18:54:05 | BlaXpirit | uint64^uint64 gives this error on 32bit system.nim(353, 5) Error: type mismatch: got (int literal(0), uint64) |
| 18:55:26 | * | irrequietus joined #nim |
| 18:56:30 | * | irrequietus quit (Read error: Connection reset by peer) |
| 18:57:27 | ldlework | BlaXpirit I've got something similar, :P |
| 18:57:29 | ldlework | /home/dlacewell/nim/dadren/dadren/generators.nim(31, 35) Error: type mismatch: got (Generator, (int, int)) |
| 18:57:31 | ldlework | but expected one of: |
| 18:57:33 | ldlework | generators.makeTile(self: StaticGenerator, pos: Point) |
| 18:57:46 | * | irrequietus joined #nim |
| 18:57:52 | ldlework | StaticGenerator is of Generator, and Point is a tuple[int, int] alias :P |
| 18:58:58 | ldlework | not sure how to move forward |
| 18:59:09 | ephja | weren't there any issues related to mixing inheritance and generics? |
| 18:59:29 | ldlework | I'm not using generics I don't think? |
| 18:59:44 | ldlework | Is specifying a base class parameter type, and passing it a subclass, utilizing generics? |
| 19:01:31 | * | yglukhov_ joined #nim |
| 19:01:31 | * | yglukhov quit (Read error: Connection reset by peer) |
| 19:02:06 | ephja | maybe I was thinking of something else. it's easy to get confused |
| 19:02:20 | ldlework | yes it is :( |
| 19:12:34 | Araq | ldlework: if StaticGenerator is of Generator you cannot pass a Generator to a StaticGenerator |
| 19:12:46 | Araq | subtyping doesn't work that way |
| 19:13:16 | ldlework | Araq: its only a "Generator" because the instance passed through library code that doesn't know about the subclass. |
| 19:13:28 | ldlework | IE, a library module provides a Generator base class and some helper methods that work on Generator. |
| 19:13:48 | ldlework | Are you saying, if I subclass a library type, I cannot pass it to any library code because that will convert it to a Generator? |
| 19:14:03 | Araq | I'm saying that it works like C# |
| 19:14:08 | ldlework | And if that library code calls back into usercode that has a user method for StaticGenerator that it wont work? |
| 19:14:58 | Araq | when A is a subtype of B, you can pass A where B is expected but not the other way round. |
| 19:15:13 | ldlework | That makes all of the library implementation utterly useless. |
| 19:15:21 | ldlework | Meaning you have to recreate all the functionality of B |
| 19:15:29 | Araq | well you can convert it explicitly |
| 19:15:41 | ldlework | But then you have to know ahead of time what kind of subclass you're getting. |
| 19:15:42 | Araq | and then at runtime it's checked you don't have any type violations |
| 19:15:43 | ephja | isn't that usually a code smell? |
| 19:15:46 | * | brson joined #nim |
| 19:15:51 | ldlework | Its library code, it doesn't know ahead of time what subclasses are created. |
| 19:16:50 | ldlework | Library provides Base, with some methods. User code creates Child with some methods. User calls a base method on Child, which calls a method provided by the base implementation but overriden in Child. The Base method gets called. |
| 19:18:02 | ldlework | I understand the idea that if you have a base type the compiler can't really be sure that you really have a specific child class instance. But how are you supposed to reuse code I wonder. |
| 19:18:08 | * | yglukhov_ quit (Remote host closed the connection) |
| 19:18:54 | Araq | I don't understand what your problem is. used "proc" intead of "method"? |
| 19:19:13 | ldlework | https://gist.github.com/dustinlacewell/30cf22216feab04fbe34 |
| 19:19:15 | ldlework | two types |
| 19:19:22 | ldlework | Generator and StaticGenerator |
| 19:19:30 | ldlework | There are two base methods, getChunk and getTile |
| 19:19:45 | ldlework | StaticGenerator overrides "getTile", and keeps the base implementation of "getChunk" |
| 19:19:52 | ldlework | In my code I call "getChunk" on StaticGenerator |
| 19:20:01 | ldlework | When it hits the last line of that for-loop, when it calls "getTile" |
| 19:20:05 | ldlework | It calls Generator.getTile |
| 19:20:09 | ldlework | This seems useless. |
| 19:20:52 | Araq | method makeTile*(self: StaticGenerator, pos: Point): Tile |
| 19:21:11 | Araq | surely is generic and as I said, methods with generics don't work properly |
| 19:21:19 | ldlework | Why is it generic? |
| 19:21:27 | ldlework | Honest question. |
| 19:21:30 | Araq | because StaticGenerator is. |
| 19:22:03 | ldlework | So if I made a StaticGenerator that worked with a specific T, it would work? |
| 19:22:16 | Araq | perhaps. |
| 19:22:36 | Araq | I think so. |
| 19:22:55 | ldlework | I wonder if PyPy is as easy to use as it is fast, these days. |
| 19:23:24 | ldlework | just kidding! |
| 19:23:39 | ldlework | Araq: Can you make another suggestion on how to offer this kind of functionality to users as a library? |
| 19:23:51 | ldlework | Offer some base types, let them override parts of the functionality but reuse most of it? |
| 19:24:56 | Araq | well makeChunk is 10 lines of code. I would expose it as a template and call it a day. |
| 19:25:03 | * | irrequietus quit () |
| 19:25:14 | ldlework | wow |
| 19:25:17 | Araq | but you can also pass a closure to it. |
| 19:25:19 | ldlework | There's nothing else? |
| 19:25:28 | ldlework | Passing around closures seems just as broken. |
| 19:25:47 | ldlework | I can't seem to enclose over the types that need to be available when the closure is called. |
| 19:26:30 | Araq | you cannot capture a var or an openarray. simple solution: turn the 'var' into a 'ref' and the openarray into a seq |
| 19:27:05 | Araq | it shouldn't be too hard to understand why you cannot capture something that might live on the stack and at the same time cannot be copied. |
| 19:27:16 | ldlework | Yeah I think I see what you're saying |
| 19:27:22 | ldlework | Even though my thing is var, its still an object type. |
| 19:27:28 | ldlework | But a reference will capture. |
| 19:27:48 | ldlework | But I cannot wrap my mind around the fact that "code reuse" == "ship a template" |
| 19:27:54 | ldlework | Are you happy with that? |
| 19:28:00 | BlaXpirit | nim c --passC:-m32 /usr/lib/nim/nimbase.h:412:13: error: size of array ‘assert_numbits’ is negative |
| 19:28:01 | BlaXpirit | typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1]; |
| 19:28:12 | BlaXpirit | 32bit compilation on 64bit linux fails^ |
| 19:28:58 | * | l joined #nim |
| 19:29:08 | * | l quit (Client Quit) |
| 19:30:09 | Araq | ldlework: as I said, you can use closures or templates or inheritance. |
| 19:30:20 | ldlework | But inheritance doesn't work for library code. |
| 19:30:53 | ldlework | I'll try closures again I guess. |
| 19:33:29 | Araq | BlaXpirit: nim c --cpu:x86 --passC:-m32 |
| 19:34:01 | BlaXpirit | Araq, unknown CPU: 'x86' |
| 19:34:15 | Araq | try i386 then or whatever |
| 19:34:17 | dom96 | hello guys |
| 19:40:15 | def- | BlaXpirit: also --passL:-m32 |
| 19:40:56 | BlaXpirit | def-, oh, that was the last piece of the puzzle. |
| 19:40:58 | BlaXpirit | thanks! |
| 19:44:00 | * | ics quit (Quit: Connection closed for inactivity) |
| 19:44:06 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 19:52:46 | * | brson quit (Quit: leaving) |
| 19:56:14 | * | endragor joined #nim |
| 20:04:32 | ldlework | Passing closures is kinda gross. Lets say there is only Generator, and instead of subclassing it to override getTile, it just takes a closure for that "method" instead. How do you offer, in library form, several "prebaked" versions of Generator? By creating new types that are *not* Generators, but have a Generator field to which you wrap Generator and pass it the prebaked implementation as a closure? So then, |
| 20:04:32 | * | Arrrr left #nim ("WeeChat 1.2") |
| 20:04:34 | ldlework | you have to write stupid little pass through functions like getChunk which just calls self.generator.getChunk? Boilerplate abound, my mortal weakness! |
| 20:06:23 | ldlework | And then that wrapper is not a Generator anymore. |
| 20:06:31 | ldlework | And you have to hope that concepts work. |
| 20:09:53 | * | baff1e quit (Remote host closed the connection) |
| 20:20:33 | Araq | a "generator" is a first class function, not a class |
| 20:20:51 | Araq | get rid of the class altogether and the boilerplate vanishes too |
| 20:21:47 | ldlework | I think I understand what you're getting at and I'll play with that idea. |
| 20:23:48 | ldlework | The problem is that some of them will indeed have state and even nest each other. |
| 20:23:57 | ldlework | So that for some ranges of input values, they defer to child generators. |
| 20:24:12 | Araq | the state is the closure's environment |
| 20:25:34 | ldlework | Araq: btw, is the problem with methods and generics a Hard Problem academically, or is the difficulty more pragmatic in nature, etc? |
| 20:26:58 | Araq | I think it's just a hard problem in general and not really specific to Nim. but tbh I have to check what C# does. |
| 20:27:30 | Araq | C# supports multi methods too iirc |
| 20:27:41 | Araq | but it's a well kept secret. |
| 20:29:33 | ephja | a secret? really? |
| 20:30:27 | * | Jesin quit (Quit: Leaving) |
| 20:31:57 | * | cratuki left #nim (#nim) |
| 20:41:43 | ldlework | Well here's a minimal example, https://gist.github.com/dustinlacewell/d8fc8e5affca220d8e76 |
| 20:41:52 | ldlework | removed from the context of tile generators, etc |
| 20:52:35 | ldlework | Why doesn't this one work? https://gist.github.com/dustinlacewell/4a6ba76d56be746aaa53 |
| 20:52:57 | ldlework | cm.nim(10, 23) Error: type mismatch: got (Factory[system.int]) |
| 20:53:04 | ldlework | Why is it treating Factory as a type? |
| 20:55:31 | ephja | so getValues is declared before getValue? |
| 20:56:23 | ldlework | It has to be |
| 20:56:25 | ldlework | its a library function |
| 20:56:33 | ldlework | defined before the user even dreams up their application |
| 20:57:04 | ldlework | It does something more complicated in my real application this is a super trivial example |
| 21:04:27 | toaoMgeorge | Just curious... wouldn't it be nice for runtime polymorphism to have something similar to swift/clojure protocols? I understand that this kind of things doesn't really fit Nim, but they would be a nicer alternative than multimethods or closures when needed and, unlike interfaces, they don't force over-complicated designs on you... (I also have suspect that they may be implemented easily with macros, I don't know well how though) |
| 21:05:07 | toaoMgeorge | They should be like extensible interfaces and without need to be explicity declared for a type, kinda like concepts but for runtime and with interface-like behaviour... I don't really know how I repeat, I just have some confused idea... |
| 21:05:49 | ldlework | Looking at Crystal's docs for the first time, I wish it was as easy as their story. |
| 21:05:56 | ldlework | Create a class, inherit from it, override whatever you want. |
| 21:06:19 | ldlework | Though I wonder if their generics work well with their methods. |
| 21:09:00 | ephja | ldlework: did you export the library procs? |
| 21:09:10 | ephja | anyway, maybe the signature in the concept should be enough |
| 21:09:20 | ldlework | ephja: its in a single file |
| 21:09:28 | ldlework | just run the file :) |
| 21:09:47 | ldlework | it doesn't work though it kinda looks like it should |
| 21:14:16 | * | brson joined #nim |
| 21:21:34 | * | apotheon_ is now known as apotheon |
| 21:21:51 | * | apotheon quit (Changing host) |
| 21:21:51 | * | apotheon joined #nim |
| 21:23:39 | * | nsf quit (Quit: WeeChat 1.4) |
| 21:28:51 | gokr | Araq: Any bright ideas on why the calls I mentioned earlier (systemInit000 and systemDatInit000) makes my blink break? |
| 21:30:40 | Araq | no |
| 21:31:45 | gokr | Funny thing, if I comment them both out - it works. If I then enable the systemDatInit000 call (which apparently doesn't do anything) - it stops working. |
| 21:33:14 | * | gour quit (Quit: WeeChat 1.4) |
| 21:38:30 | Araq | I wish I knew why nobody can understand there is a trivial bijection between interface and tuple of closures ... |
| 21:41:03 | ldlework | Araq: what do you mean? |
| 21:47:26 | * | Varriount_ joined #nim |
| 21:47:26 | * | Varriount quit (Disconnected by services) |
| 21:52:40 | * | pregressive quit (Remote host closed the connection) |
| 21:53:04 | * | mat4 joined #nim |
| 21:53:11 | mat4 | hello |
| 21:53:53 | * | Wildefyr joined #nim |
| 21:53:57 | ephja | ahoy-hoy |
| 21:56:12 | mat4 | -joy |
| 22:16:39 | * | vendethiel quit (Quit: q+) |
| 22:18:38 | Varriount_ | ldlework: How goes things? |
| 22:18:58 | ldlework | Pretty sad :/ |
| 22:22:47 | ldlework | Crystal implementation of the simple library factory: https://carc.in/#/r/s2o |
| 22:23:07 | ldlework | too bad its syntax is ugly as hell |
| 22:28:43 | * | biscarch joined #nim |
| 22:31:31 | toaoMgeorge | Araq: maybe the closures solution you suggest would be enough to overcome the lack of protocols, interfaces, whatever, but, as a beginner, I admit I wouldn't have been able to do it in an elegant way without your advice, and a unified syntax to do this sort of things would be clearer... anyway, don't worry, I won't disturb anymore with this topic... at least not before I know a little more of the language :) |
| 22:32:09 | ldlework | Generic version of crystal factory: https://gist.github.com/dustinlacewell/8ad5dd210079d3841820 |
| 22:32:22 | ldlework | I just learned Crystal doesn't support windows though. |
| 22:33:52 | * | ldlework puts a hand on his head. |
| 22:33:53 | mat4 | toaoMgeorge: what is your defination of an interface ? |
| 22:36:02 | ldlework | So I guess "like C# and Crystal do it" is the qualifier now. |
| 22:46:22 | * | Dildosan joined #nim |
| 22:51:18 | * | shodan45 joined #nim |
| 22:54:48 | * | filcuc joined #nim |
| 22:55:24 | filcuc | just a question since i don't see anything in the manual. Is procCall going to keep supported? |
| 22:55:56 | filcuc | or are methods going to be removed before 1.0 |
| 22:59:21 | Araq | dunno, seems eventually people who first like them (hey ldlework!) notice that they suck |
| 23:00:28 | * | mat4 quit (Quit: Verlassend) |
| 23:00:31 | ldlework | I wish we could make them better as other languages seem to have magic method and generic support but I can't offer anything to help :( |
| 23:01:39 | ldlework | Crystal is ugly and has no windows support but a magical type system. Its like a cruel joke. |
| 23:01:49 | filcuc | well i've a lot to say after a couple of days were i basically reworking my nimqml bindings... |
| 23:02:28 | filcuc | right now i need to call from a proc the derived implementation of a proc (so i need a method) |
| 23:03:23 | filcuc | however i find object oriented in Nim very difficult for a library maker. Don't get me wrong i'm not complaining. Really |
| 23:03:35 | filcuc | and i would like to have an hint from you |
| 23:03:38 | ldlework | filcuc: Its exactly the same thing I am experiencing. |
| 23:03:46 | ldlework | Nim is beautiful and practical but its library extension mechanism is "pass me closures." |
| 23:04:31 | filcuc | object oriented seems fine if you write everything on your own |
| 23:04:35 | ldlework | Right |
| 23:04:52 | filcuc | and you'have complete control of the code |
| 23:05:11 | ldlework | Also the method system works, just not if you need methods to be generic. |
| 23:05:29 | filcuc | seems very difficult to incapsulate something in a base class for simplify derived classes |
| 23:05:40 | ldlework | But I often do since a proc's existence as a method is orthogonal to the fact that I might want it to work with different types. |
| 23:05:45 | ldlework | Right |
| 23:05:57 | ldlework | filcuc: Basically I confirmed to day that it is impossible iwth a simple example |
| 23:05:59 | ldlework | let me show you |
| 23:06:09 | filcuc | to me reason it's that there's a complete separation between types and procs |
| 23:06:17 | filcuc | like in C |
| 23:06:23 | ldlework | filcuc: https://gist.github.com/dustinlacewell/d8fc8e5affca220d8e76 |
| 23:06:27 | filcuc | and that's is fine |
| 23:06:35 | filcuc | but for example in C++ this is not the case |
| 23:06:47 | ldlework | You'll see here a BaseFactory that implements two methods: getValue and getValues |
| 23:07:05 | ldlework | The idea is that some other library code is going to use "getValues" to get a bunch of values from the factory passed in. |
| 23:07:18 | ldlework | The idea is that the user will subclass BaseFactory and implement "getValue" |
| 23:07:41 | ldlework | But the base class "getValues" cannot call the superclass' "getValue" override. |
| 23:08:08 | ldlework | I even tried to implement it with Concepts and no inheritance: https://gist.github.com/dustinlacewell/4a6ba76d56be746aaa53 |
| 23:08:10 | ldlework | still doesn't work |
| 23:08:40 | ldlework | The answer that was given to me, was that the library code should literally take the method overrides /as parameters to a proc/ |
| 23:08:53 | ldlework | IE pass the new implementation as a parameter to a function call! |
| 23:09:08 | ldlework | So that the base class can simply call the proc passed into the base class method. |
| 23:09:47 | ldlework | This seems crazy. Because you don't write code that way otherwise. |
| 23:10:03 | filcuc | dunno if i followed everything, but why the getValues is a method? shouldn't it be a proc |
| 23:10:13 | ldlework | It doesn't really matter |
| 23:10:16 | dom96 | ldlework: have you seen the way that the `streams` module is written? |
| 23:10:42 | ldlework | dom96: can you characterize it using software design concepts? |
| 23:11:03 | Araq | hey, streams predate 'method' and would work with 'method' just as well |
| 23:11:06 | ldlework | I'll probably know what you're getting at |
| 23:11:10 | filcuc | still i don't get why the getValues method cannot call the getValue |
| 23:11:21 | * | endragor quit (Remote host closed the connection) |
| 23:11:36 | ldlework | filcuc: don't ask me. try to run the program if you don't believe it. |
| 23:11:53 | filcuc | ok give me a sec |
| 23:12:37 | ldlework | Changing getValues to a proc doesn't change anything |
| 23:12:51 | dom96 | ldlework: i'm not sure how to characterise it using those concepts. |
| 23:13:13 | ldlework | dom96: is it "provide the custom behavior by passing in a proc" ? |
| 23:13:45 | dom96 | ldlework: It's "provide the custom behaviour by storing closures in an object" |
| 23:13:51 | ldlework | same thing really |
| 23:14:08 | ldlework | I'd rather do this, but in Nim, https://gist.github.com/dustinlacewell/4f453e2ec55b2530b428 |
| 23:14:42 | * | saml quit (Quit: Leaving) |
| 23:14:42 | ldlework | Since now, I don't have to write all my library code as closure accepting functions. I can write it as normal code that doesen't expect to be extended. But then I can come along and extend it anyway. |
| 23:14:53 | filcuc | ldlework: the gist doesn't compile here :) |
| 23:14:59 | ldlework | filcuc: indeed |
| 23:15:18 | Araq | filcuc: well actually you nailed it. |
| 23:15:33 | Araq | however I can attach 'method' to the type and win. |
| 23:15:37 | filcuc | Araq: you mean with the separtion beween type and procs? |
| 23:15:42 | Araq | yes |
| 23:15:52 | filcuc | Araq: i knew it :) |
| 23:16:04 | Araq | but we can attach them to types and get rid of the multi dispatch |
| 23:16:12 | filcuc | Araq: just joking..but that's the example are C++ constructors |
| 23:16:30 | Araq | in other words, keep the syntax and change the semantics under the hood :P |
| 23:16:33 | filcuc | Araq: a constructor is attached to its type |
| 23:17:19 | Araq | but as I said, I prefer to work on more pressing things. Esp since I prefer closures anyway... |
| 23:17:30 | * | Araq <3 closures. |
| 23:17:38 | ldlework | Araq: what about the point of having to pre-expect extension |
| 23:17:54 | ldlework | where as with a normal typical method system you don't have to write everything with the expectation of extension |
| 23:18:08 | ldlework | you don't have to actually spend effort writing support for extension |
| 23:18:10 | Araq | ad-hoc extensions don't work anyway IME |
| 23:18:17 | ldlework | time you can be writing code that actually implement your business logic |
| 23:18:36 | ldlework | except that there is a trivial bijection |
| 23:18:45 | ldlework | so either they do, or closures don't |
| 23:19:06 | ldlework | or there is no trivial bijection |
| 23:20:49 | Araq | I said there is a trivial bijection to *interfaces* |
| 23:21:29 | * | arnetheduck joined #nim |
| 23:22:03 | ldlework | I'm too ignorant to know the difference |
| 23:22:50 | Araq | well the upfront design work what you find tedious is exactly what you have to do with Java interfaces and I'm sure you're familiar with them. |
| 23:23:14 | ldlework | Nope, never had the pleasure. |
| 23:23:40 | ldlework | I went from TI86 assembler to x86 assembler to C++ to C# to Python for a decade or more to Nim. |
| 23:24:54 | ldlework | All I know is that it took ~20 minutes to express this type relationship in Crystal a language I had never used before. |
| 23:27:12 | * | Demon_Fox joined #nim |
| 23:28:07 | filcuc | the thing that i don't really like it's that i cannot encapsulate nothing..what i see that can *somewhat* work is object composition |
| 23:28:43 | ldlework | Sure, user class can just compose the library types but then you're writing meaningless wrapper methods for nothing. |
| 23:28:48 | filcuc | basically to create an object that should not be subclassed but simply configured |
| 23:28:56 | ldlework | More code I have to write that has nothing to do with the logic of my program. |
| 23:29:37 | filcuc | something like what is done in rust through a builder |
| 23:29:59 | ldlework | filcuc: But like you say, for internal extension this isn't required. |
| 23:31:04 | ldlework | filcuc: "should not be subclassed but simply configured" this is fine and well for instance attributes, but for *implementation* is craziness. |
| 23:31:20 | ldlework | "Here is how you should implement foo, and this is how you should implement bar and ..." |
| 23:31:40 | ldlework | this boilerplate has been solved |
| 23:33:44 | filcuc | ldlework: what i see it's that since inheritance cannot enforce nothing (think about nim constructor and c++ constructor. The latter are enforced you cannot skip them instead in nim you can) the only thing you can do it's to create an object that has all the customization point you want and enforce your rules inside it. For the end user provide a Rust builder interface for creating this object and be done with it |
| 23:34:28 | filcuc | Araq: an example are finalizer |
| 23:34:54 | filcuc | Since the newFoo or newBar cannot be inherited |
| 23:35:14 | * | shodan45 quit (Quit: Konversation terminated!) |
| 23:35:24 | filcuc | a base class cannot enforce that the derives class will call its finalizer |
| 23:35:48 | ldlework | I don't know what you're saying at all |
| 23:35:55 | * | nsf joined #nim |
| 23:36:16 | Araq | last time I checked even tut2 says something like that "OO is supported but not as convenient as in other languages" |
| 23:36:39 | ldlework | Its not really supported though is it? |
| 23:37:47 | filcuc | ldlework: see https://gist.github.com/filcuc/47389bacef9540971032 |
| 23:38:08 | filcuc | basically type B should know that A needs a finalizer |
| 23:38:22 | Araq | filcuc: we have "type bound" procedures for that but finalizers predate them |
| 23:38:54 | filcuc | if the user who implement B forget to write new(result, delete) something bad could happen |
| 23:39:12 | filcuc | in my case a C object is not deallocated |
| 23:39:18 | ldlework | filcuc: that's different than not being able to write new(result, delete) at all |
| 23:39:20 | ldlework | because it wont compile |
| 23:39:23 | ldlework | :/ |
| 23:39:25 | Araq | sure go on, beat a dead horse |
| 23:39:53 | ldlework | Araq: why doesn't the concept version work? |
| 23:40:04 | ldlework | https://gist.github.com/dustinlacewell/4a6ba76d56be746aaa53 |
| 23:40:46 | filcuc | ldlework: i'm talking about my use case and why i don't see a way to enforce something through inheritance |
| 23:41:00 | filcuc | for example the invokation of a finalizer |
| 23:41:08 | ldlework | filcuc: I know I'm just saying, you could still implement it manually |
| 23:41:11 | ldlework | I can't even do that. |
| 23:41:37 | ldlework | Unless that means you take manually for me to mean "forego oo all together and literally pass implementations around" |
| 23:41:46 | ldlework | then sure I too can manually do it. |
| 23:42:00 | Varriount_ | Araq: Closures are nice... It's just a shame they carry so much overhead. |
| 23:43:32 | ldlework | If the Concept version worked at least, then I could at least expose concepts that user implementations needed to adhere to. |
| 23:43:45 | ldlework | That way they could benefit from existing implementations that used that concept like getValues() in that example |
| 23:43:47 | ldlework | But nope. |
| 23:46:27 | * | Trustable quit (Remote host closed the connection) |
| 23:48:10 | * | BitPuffin|osx joined #nim |
| 23:49:01 | filcuc | ldlework: this seems to work here https://gist.github.com/filcuc/e01ddc32671504d4f160 |
| 23:49:09 | filcuc | i mean without generics |
| 23:49:18 | dom96 | perhaps it's time to consider non-OO approaches. |
| 23:49:21 | ldlework | Sure, but then there is no point. |
| 23:49:31 | ldlework | I need N StaticGenerator implementations |
| 23:49:43 | ldlework | and I might as well use Golang |
| 23:49:56 | ldlework | dom96: already considered them though |
| 23:49:59 | filcuc | ldlework: yep i understand that |
| 23:50:02 | ldlework | and they suck and have serious downsides |
| 23:50:12 | ldlework | including boilerplate that has nothing to do with business logic |
| 23:50:57 | dom96 | ldlework: which ones did you consider? |
| 23:51:22 | ldlework | "pass in a structure of closures containing the novel implementation" |
| 23:51:59 | * | derka joined #nim |
| 23:52:05 | ldlework | "compose novel implementations from library types and spend your weekend writing stupid pass through procs on wrapper types" |
| 23:52:28 | ldlework | Am I missing any because that seems to be it. |
| 23:52:46 | ldlework | I thought "Use concepts to enforce constraints on novel implementations allowing you to call them like generic functions" |
| 23:52:55 | ldlework | but that didn't work out well, https://gist.github.com/dustinlacewell/4a6ba76d56be746aaa53 |
| 23:52:59 | ldlework | haven't gotten an answer why it doesn't work |
| 23:54:01 | Araq | sorry, I'm busy sitting around watching porn |
| 23:54:18 | filcuc | :D |
| 23:55:51 | ldlework | Each one besides the last reads to me "do what other languages besides Nim do for you, except they do everything else worse" |
| 23:55:58 | ldlework | which is why I'm sad :D |
| 23:57:44 | Araq | speaking of which, I figured out why my new GC doesn't work :-) |
| 23:58:29 | ephja | faulty code? |
| 23:59:39 | ldlework | But why doesnt the concept version work?! |
| 23:59:59 | * | Matthias247 quit (Read error: Connection reset by peer) |