| 00:10:54 | * | a__b__m quit (Quit: Leaving) |
| 00:43:04 | * | rnrwashere joined #nim |
| 01:00:03 | * | rnrwashere quit (Remote host closed the connection) |
| 01:01:38 | * | rnrwashere joined #nim |
| 01:04:12 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 01:05:51 | * | rnrwashere quit (Remote host closed the connection) |
| 01:13:24 | * | fredrik92 quit (Quit: Client Disconnecting) |
| 01:23:24 | * | I_Right_I joined #nim |
| 01:27:51 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 01:46:35 | * | rnrwashere joined #nim |
| 01:54:09 | * | rnrwashere quit (Remote host closed the connection) |
| 02:24:17 | * | rnrwashere joined #nim |
| 02:29:03 | * | noeontheend quit (Remote host closed the connection) |
| 02:54:20 | * | theelous3_ quit (Ping timeout: 250 seconds) |
| 03:05:59 | * | banc quit (Quit: Bye) |
| 03:07:01 | * | dddddd quit (Remote host closed the connection) |
| 03:19:28 | * | rnrwashere quit (Remote host closed the connection) |
| 03:26:01 | * | rnrwashere joined #nim |
| 03:27:33 | * | banc joined #nim |
| 03:30:48 | * | Cthalupa quit (Ping timeout: 246 seconds) |
| 03:31:49 | * | Dragon-Warrior joined #nim |
| 03:32:54 | * | Cthalupa joined #nim |
| 03:49:45 | * | rnrwashere quit (Remote host closed the connection) |
| 03:50:21 | * | rnrwashere joined #nim |
| 03:54:27 | * | rnrwashere quit (Ping timeout: 240 seconds) |
| 03:55:48 | * | kapil____ joined #nim |
| 04:00:30 | * | rnrwashere joined #nim |
| 04:10:26 | * | rnrwashere quit (Remote host closed the connection) |
| 04:12:28 | * | cgfuh quit (Quit: WeeChat 2.3) |
| 04:28:04 | * | rnrwashere joined #nim |
| 04:38:08 | * | nsf joined #nim |
| 04:54:25 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:02:23 | * | I_Right_I quit (Remote host closed the connection) |
| 05:06:07 | * | mal`` quit (Quit: Leaving) |
| 05:10:58 | * | mal`` joined #nim |
| 05:20:33 | * | rnrwashere quit (Remote host closed the connection) |
| 06:01:35 | * | narimiran joined #nim |
| 06:02:01 | Araq | https://forum.dlang.org/post/[email protected] so they are waking up in D-land too. |
| 06:02:46 | Araq | This is also what we should do, stop deprecating stuff that is "wrong", add new stuff instead |
| 06:15:54 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 06:22:40 | * | kapil____ joined #nim |
| 06:33:49 | * | solitudesf joined #nim |
| 06:34:58 | * | sealmove quit (Quit: WeeChat 2.4) |
| 06:37:52 | FromGitter | <cabhishek> n |
| 06:44:06 | * | uvegbot quit (Remote host closed the connection) |
| 06:45:00 | * | uvegbot joined #nim |
| 06:54:13 | * | nc-x joined #nim |
| 06:54:28 | nc-x | i disagree |
| 06:56:02 | nc-x | i don't want a language that keeps on adding stuff and not removing badly designed features |
| 06:57:07 | nc-x | backward compatibility vs mischief causing capability should be taken into consideration to decide whether something should remain or not |
| 06:58:42 | nc-x | also too many features create a big learning difficulty. e.g. c++ requires a lot of years to learn how to use properly |
| 06:59:36 | nc-x | and then people write manifestos on how to write c++. dont use this, dont use that, etc. |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:00:18 | nc-x | too less features also makes people use anti-patterns |
| 07:00:26 | nc-x | so things should be balanced |
| 07:00:43 | nc-x | and I think Nim is going pretty good atm. |
| 07:04:55 | * | gmpreussner joined #nim |
| 07:05:09 | * | nc-x quit (Ping timeout: 256 seconds) |
| 07:07:25 | * | krux02 joined #nim |
| 07:21:04 | * | PMunch joined #nim |
| 07:30:08 | * | Trustable joined #nim |
| 07:31:15 | * | solitudesf quit (Ping timeout: 244 seconds) |
| 07:37:57 | * | uvegbot quit (Remote host closed the connection) |
| 07:38:11 | * | sutke1178 joined #nim |
| 07:38:22 | * | pwntus quit (Ping timeout: 245 seconds) |
| 07:39:12 | * | uvegbot joined #nim |
| 07:40:33 | * | sutke11782 quit (Ping timeout: 244 seconds) |
| 07:46:37 | * | rokups joined #nim |
| 08:20:47 | * | mal`` quit (Quit: Leaving) |
| 08:30:17 | * | mal`` joined #nim |
| 08:42:53 | FromGitter | <Varriount> Araq: You have to be careful though, otherwise you end up with situations like PHP's mysql_real_escape_string |
| 08:44:52 | * | narimiran_ joined #nim |
| 08:47:07 | * | narimiran quit (Ping timeout: 245 seconds) |
| 08:49:53 | Araq | I dunno, once we are as successful as PHP and C++ we are allowed to complain about it. |
| 08:51:18 | Araq | maybe the development process that leads to success is also the development process that keeps cruft for a looong time |
| 09:07:37 | * | pwntus joined #nim |
| 09:07:37 | * | pwntus quit (Changing host) |
| 09:07:37 | * | pwntus joined #nim |
| 09:12:06 | * | neceve joined #nim |
| 09:18:05 | FromGitter | <mratsim> you need something to show for people to start complaining :P |
| 09:18:17 | FromGitter | <mratsim> Good enough goes a long way |
| 09:19:07 | FromGitter | <mratsim> deprecating stuff to avoid being hindered by legacy/bad decisions because we didn't know enough a couple years ago is OK though |
| 09:19:14 | FromGitter | <mratsim> otherwise you get windows |
| 09:21:34 | FromGitter | <Varriount> Araq: With the checkRefs switch, a positive reference count on an unowned reference will always abort the program? |
| 09:22:16 | FromGitter | <Varriount> (when the object is deallocated) |
| 09:22:39 | FromGitter | <Varriount> Will there be any way to customize that? |
| 09:23:07 | FromGitter | <Varriount> And how will this interact with threads? Will atomic reference counting be used? |
| 09:23:42 | Araq | if the checks are on it will always abort, quite deterministically so testing your program helps |
| 09:24:17 | Araq | it also fails more quickly than valgrind because the existence of the dangling ref is detected, not when it's used later on |
| 09:25:36 | Araq | there won't be a way to customize this but keep in mind that with the flexible destructors you can write your own shared_ptr that nils the weak references or does other more crazy stuff |
| 09:26:20 | Araq | for 'ref' which is used everywhere in the stdlib it's the right set of semantics for all know. |
| 09:26:52 | Araq | we need a prototype and see but I did some analysis. |
| 09:27:19 | Araq | the RC ops will be atomic for thread safety, yes. |
| 09:37:06 | * | ng0 joined #nim |
| 09:52:37 | * | stefanos82 joined #nim |
| 10:02:16 | * | Vladar joined #nim |
| 10:17:04 | * | narimiran_ is now known as narimiran |
| 10:21:34 | * | rnrwashere joined #nim |
| 10:25:53 | * | rnrwashere quit (Ping timeout: 245 seconds) |
| 10:40:32 | * | abm joined #nim |
| 10:55:20 | FromGitter | <Varriount> Araq: I guess I'm rather skeptical that the benefits of the proposed model will outweigh the downsides. |
| 10:56:38 | FromGitter | <Varriount> One of the things that drew me to Nim in the first place was that it had garbage collection. This feels like a step back, towards C++ smart pointers. |
| 10:58:51 | FromGitter | <mratsim> You can still rely on GC though |
| 10:59:23 | FromGitter | <mratsim> In my case I need more fine grained memory control |
| 10:59:41 | FromGitter | <Varriount> @mratsim "the GC" simply becomes reference counting, which is what smart pointers do. |
| 10:59:53 | FromGitter | <mratsim> it already is refcounting |
| 11:00:26 | FromGitter | <Varriount> But not refcounting everything |
| 11:02:56 | FromGitter | <mratsim> it says that it will not refcount stack assignments, like today |
| 11:03:52 | FromGitter | <Varriount> If anything, the proposal is even less flexible than what C++ has - the proposal essentially restricts you to using only unique and raw pointers (references) |
| 11:04:28 | livcd | How would I go about merging chunks of smaller files into a bigger chunk ? |
| 11:06:21 | FromGitter | <Varriount> livcd: Open the output file, open each input file, then repeatedly read data from each into a buffer, which you then write into your output file. |
| 11:06:35 | FromGitter | <Varriount> *each input file |
| 11:07:03 | FromGitter | <Varriount> livcd: You could also look at the implementation of the `cat` utility |
| 11:08:06 | livcd | ok thanks. I am trying to search in lots of small files |
| 11:15:47 | Zevv | Varriount: Don't look at GNU cat, its a *bad* example |
| 11:16:28 | * | theelous3_ joined #nim |
| 11:32:18 | FromGitter | <alehander42> Is there a Nim treesitter grammar |
| 11:32:28 | FromGitter | <alehander42> Or something like that |
| 11:32:36 | FromGitter | <alehander42> Maybe @shashlick |
| 11:36:11 | * | rokups quit (Quit: Connection closed for inactivity) |
| 11:42:07 | * | Dragon-Warrior quit (Ping timeout: 245 seconds) |
| 11:45:53 | * | Dragon-Warrior joined #nim |
| 11:49:49 | FromGitter | <Varriount> @alehander42 I believe someone was using treesitter to handle C binding generation. |
| 11:57:32 | * | sealmove joined #nim |
| 12:02:19 | Araq | Varriount: the "raw" pointers are still checked and that makes all the difference for me |
| 12:03:20 | Araq | and graphs are intrinsically more complex than trees, if you use a graph to model trees, it's wrong |
| 12:04:09 | Araq | there are no good algorithms that support general graphs and scale to terabyte heap sizes |
| 12:04:47 | * | Snircle joined #nim |
| 12:06:07 | Araq | give me a single file system implementation that uses tracing |
| 12:09:07 | * | Vladar quit (Remote host closed the connection) |
| 12:10:35 | FromGitter | <Varriount> Araq: https://en.wikipedia.org/wiki/Singularity_(operating_system) |
| 12:13:25 | FromGitter | <mratsim> @livcd, instead of writing to a buffer directly write to a stream |
| 12:16:09 | Araq | I said "file system" |
| 12:16:32 | Araq | not "operating system", an OS is ok with GC |
| 12:39:12 | shashlick | @alehander42 - nimterop uses tree-sitter to read c/c++ |
| 12:39:23 | shashlick | But there's no Nim grammar so far |
| 12:41:18 | shashlick | http://tree-sitter.github.io/tree-sitter/#available-parsers |
| 12:41:38 | shashlick | There's 14 supported languages, 6 more in development |
| 12:44:03 | * | rokups joined #nim |
| 13:21:44 | * | Dragon-W1rrior joined #nim |
| 13:21:56 | * | Dragon-Warrior quit (Read error: Connection reset by peer) |
| 13:26:13 | * | nsf quit (Quit: WeeChat 2.4) |
| 13:29:25 | FromGitter | <liquid600pgm> oh well, `static bool = true` doesn't work anywhere it seems |
| 13:29:41 | FromGitter | <liquid600pgm> I just tried adding it to a proc, no luck |
| 13:30:42 | FromGitter | <liquid600pgm> oops, it was my fault actually |
| 13:33:57 | shashlick | Try passing false, I don't think that works |
| 13:34:19 | FromGitter | <liquid600pgm> both work, it was just an error in a `when` block |
| 13:41:25 | FromGitter | <liquid600pgm> I was fixing a bug which appeared when I was testing if passing `false` causes errors with procs |
| 13:43:15 | FromGitter | <arnetheduck> > <Araq> This is also what we should do, stop deprecating stuff that is "wrong", add new stuff instead ⏎ ⏎ this works well if your language is equipped with the infrastructure to add new stuff (like the D versioning/namespacing).. nim is tricky - every symbol lives in the global namespace by default.. if I import something, the author of that library can (very) easily break my code by adding a symbol, if I just |
| 13:43:15 | FromGitter | ... follow the "normal" way of using nim. I have to fight the language to prevent this, and it's uphill. ⏎ ⏎ thus, before committing to maintenance, ensure there actually exists a way to add things that is practical - and the smaller your starting point, the easier that becomes. [https://gitter.im/nim-lang/Nim?at=5c9e20f2e4561321d05a671f] |
| 13:45:21 | FromGitter | <arnetheduck> that said, I'm all for add-only - this is what package management generally is about - you have a repository of "old stuff" that *never* changes, and you can choose if you want the new stuff or not in a more manageable way, library by library instead of one huge std lib + language where you have to accept *all* changes to get a small one |
| 13:46:53 | FromGitter | <arnetheduck> from the post: `We have a language with virtually no global scope ` <- of course it's easy to keep adding stuff then |
| 13:48:54 | FromGitter | <liquid600pgm> does `{.bycopy.}` do a shallow or deep copy? |
| 13:49:07 | * | Cadair left #nim ("User left") |
| 13:49:27 | FromGitter | <mratsim> nothing of the sort |
| 13:49:39 | FromGitter | <liquid600pgm> what does it do then? |
| 13:50:02 | FromGitter | <mratsim> By default if an object is bigger than 3x pointer size, Nim passes it via pointer |
| 13:50:11 | FromGitter | <mratsim> you can check that in your code |
| 13:50:24 | FromGitter | <mratsim> if you use the bycopy pragma, Nim will not do this optimisation |
| 13:50:58 | FromGitter | <mratsim> if you use the byref pragma, Nim will always pass it by pointer even though it could be faster by with passing it via registers (in fastcall convention) |
| 13:51:12 | FromGitter | <mratsim> the main use case is interfacing with C/C++ |
| 13:51:23 | FromGitter | <liquid600pgm> good to know. the manual was a little vague on this so I preferred to ask than wonder |
| 13:52:16 | FromGitter | <mratsim> so bycopy/byref does not change assignment semantics but parameter passing |
| 13:52:36 | FromGitter | <liquid600pgm> now, another question: are object variants just tagged unions? or are they something else? |
| 13:52:48 | FromGitter | <mratsim> plain tagged unions |
| 13:53:07 | FromGitter | <liquid600pgm> thanks |
| 13:53:08 | FromGitter | <mratsim> also called sum types in ML countries ;) |
| 13:55:00 | FromGitter | <liquid600pgm> I mean, using tagged unions makes sense here, using different types would be pretty weird |
| 13:55:47 | FromGitter | <liquid600pgm> and complex to compile |
| 14:02:56 | * | Vladar joined #nim |
| 14:04:01 | * | Dragon-W1rrior quit (Quit: leaving) |
| 14:14:02 | * | cgfuh joined #nim |
| 14:14:21 | FromGitter | <arnetheduck> btw, the default nim GC, is it.. quadratic, in terms of performance? ie the more I allocate, the more it has to scan? |
| 14:17:56 | FromGitter | <mratsim> I managed to load the official EF state tests yeah :) |
| 14:18:15 | Araq | arnetheduck: I'm not aware of any quadratic behaviour |
| 14:18:25 | FromGitter | <mratsim> arg wrong chat again |
| 14:19:17 | FromGitter | <arnetheduck> quadratic in the sense that when I allocate N times, it will call GC N/constant times, and the time gc takes is proportional to the memory allocated |
| 14:20:14 | Araq | it uses a watermark and it's like nextAllocationAtCurrentMem * 2 |
| 14:30:16 | * | rnrwashere joined #nim |
| 14:34:36 | * | rnrwashere quit (Ping timeout: 250 seconds) |
| 14:39:21 | * | solitudesf joined #nim |
| 14:39:59 | * | PMunch quit (Remote host closed the connection) |
| 14:57:16 | * | rnrwashere joined #nim |
| 14:59:16 | * | dddddd joined #nim |
| 15:11:20 | * | a_b_m joined #nim |
| 15:14:25 | * | abm quit (Ping timeout: 246 seconds) |
| 15:22:17 | * | thomasross_ joined #nim |
| 15:22:18 | * | thomasross quit (Killed (asimov.freenode.net (Nickname regained by services))) |
| 15:22:18 | * | thomasross_ is now known as thomasross |
| 15:23:25 | * | redlegion quit (Ping timeout: 255 seconds) |
| 15:24:41 | * | redlegion joined #nim |
| 15:24:41 | * | redlegion quit (Changing host) |
| 15:24:41 | * | redlegion joined #nim |
| 15:29:27 | * | d10n-work joined #nim |
| 15:42:30 | * | stefanos82 quit (Remote host closed the connection) |
| 15:55:20 | * | Snircle_ joined #nim |
| 15:55:30 | * | Snircle quit (Ping timeout: 250 seconds) |
| 16:32:18 | * | Snircle joined #nim |
| 16:33:25 | * | Snircle quit (Client Quit) |
| 16:34:12 | * | Snircle_ quit (Ping timeout: 245 seconds) |
| 16:40:14 | * | rnrwashere quit (Remote host closed the connection) |
| 16:40:19 | * | neceve quit (Quit: No Ping reply in 180 seconds.) |
| 16:41:23 | * | nsf joined #nim |
| 16:44:55 | * | rnrwashere joined #nim |
| 16:45:49 | * | I_Right_I joined #nim |
| 16:47:30 | * | neceve joined #nim |
| 16:50:17 | * | Snircle joined #nim |
| 16:51:56 | * | rnrwashere quit (Remote host closed the connection) |
| 16:52:53 | * | rnrwashere joined #nim |
| 17:06:40 | * | rnrwashere quit (Remote host closed the connection) |
| 17:16:11 | * | rokups quit (Quit: Connection closed for inactivity) |
| 17:35:01 | * | a_b_m quit (Quit: Leaving) |
| 17:36:24 | * | clyybber joined #nim |
| 17:46:01 | * | stefanos82 joined #nim |
| 17:48:06 | * | sealmove quit (Quit: WeeChat 2.4) |
| 17:55:29 | FromGitter | <kdheepak> If I have a large pascal codebase that I want to convert to nim, is there anything that I can use? |
| 17:55:51 | FromGitter | <kdheepak> My understanding is that the nim compiler was bootstrapped from pascal, right? |
| 18:05:49 | * | natrys joined #nim |
| 18:07:13 | * | Cthalupa quit (Ping timeout: 255 seconds) |
| 18:08:15 | * | Cthalupa joined #nim |
| 18:14:08 | narimiran | kdheepak: maybe https://github.com/nim-lang/pas2nim ? |
| 18:17:50 | FromGitter | <kdheepak> Thanks, just found that as well. |
| 18:24:25 | FromGitter | <kdheepak> I think the codebase I'm using has a lot of classes + inheritance |
| 18:24:47 | FromGitter | <kdheepak> I don't know enough about pascal at the moment to know exactly what I'm dealing with. I'll look into it further. |
| 18:30:02 | * | I_Right_I quit (Remote host closed the connection) |
| 18:35:33 | * | rnrwashere joined #nim |
| 18:43:47 | * | zestyr quit (Quit: WeeChat 2.4) |
| 18:46:37 | * | rnrwashere quit (Remote host closed the connection) |
| 18:49:10 | * | rnrwashere joined #nim |
| 18:54:01 | * | rnrwashere quit (Remote host closed the connection) |
| 18:57:19 | * | skaruts joined #nim |
| 18:58:59 | skaruts | if I have a type Point with a x and y fields, is there a way to make it so it can accept both ints and floats? |
| 19:00:12 | Araq | floats can hold most integers |
| 19:01:03 | Araq | floats are not "imprecise" numbers, they are more like fractions with flexible precision but integer values are fine |
| 19:02:23 | skaruts | but if I define them as floats I'll have to cast to int if I do any arithmetic, right? |
| 19:02:40 | skaruts | (with other stuff that's defined as int) |
| 19:03:52 | skaruts | like p.x - camera.pos.x (or p - camera.pos) |
| 19:04:33 | Araq | there are about three ways to handle that |
| 19:04:42 | Araq | 1. introduce a converter from float to int |
| 19:05:19 | Araq | 2. introduce an operator for the conversion so that it's short |
| 19:05:55 | Araq | 3. live with the int() syntax, it won't kill you |
| 19:06:04 | skaruts | :) |
| 19:06:11 | skaruts | tbh, I'm not needing floats, I'm just wondering how to generalize my Point type for the potential future |
| 19:06:48 | skaruts | but yea, converters... I was meaning to read more about those (saw it in nim-csfml for vector types) |
| 19:06:53 | Araq | then YAGNI applies, the only buzzword that makes sense |
| 19:07:50 | * | neceve quit (Read error: Connection reset by peer) |
| 19:08:53 | skaruts | btw I ended up doing the ECS like you were saying |
| 19:10:10 | skaruts | using sequences, and keeping a lookup table for by_id lookups |
| 19:11:40 | skaruts | oh btw, I found myself having to cast enum fields to int every time I use them as indices to sequences, is this normal behavior? |
| 19:12:11 | skaruts | entity.comps[int(Visible)] |
| 19:17:20 | Araq | for seqs yes but for arrays you can do array[EnumType, T] |
| 19:18:02 | Araq | you can introduce custom [], []= accessors for the seqs. |
| 19:18:18 | skaruts | oh! |
| 19:18:36 | skaruts | gonna try that |
| 19:22:37 | skaruts | I suppose it's like this: |
| 19:22:39 | skaruts | proc `[]`*(c:Comps):int = result = int(c) |
| 19:22:45 | skaruts | seems to work |
| 19:23:47 | skaruts | (it's not compiling due to other stuff, so I can't test it to be sure) |
| 19:25:00 | clyybber | [] needs two arguments |
| 19:25:18 | Araq | proc `[]`*(c: var Comps; i: MyEnum): var int = c[int i] |
| 19:25:23 | Araq | proc `[]`*(c: Comps; i: MyEnum): int = c[int i] |
| 19:25:30 | skaruts | Comps is the enum |
| 19:25:42 | Araq | proc `[]=`*(c: var Comps; i: MyEnum; val: int) = c[int i] = val |
| 19:25:49 | Araq | you need all three |
| 19:25:59 | Araq | (yeah, yeah, sucks I know I know, whatever) |
| 19:26:19 | clyybber | Araq: Why do you need the first one? |
| 19:26:49 | skaruts | but Comps it my enum, so I'm confused about the "MyEnum" part |
| 19:27:08 | clyybber | replace MyEnum with Comps and Comps with your seq type |
| 19:27:14 | skaruts | ah |
| 19:27:50 | * | rnrwashere joined #nim |
| 19:28:07 | Araq | a[i] means [] is a binary operation |
| 19:28:53 | * | rnrwashere quit (Remote host closed the connection) |
| 19:28:59 | * | rnrwashere joined #nim |
| 19:30:10 | skaruts | so I suppose it should be like this: |
| 19:30:13 | skaruts | proc `[]`*(c: var seq[Component]; i: Comps): var int = c[int i] |
| 19:30:26 | skaruts | (made the same changes for the other two) |
| 19:31:03 | Araq | yes |
| 19:32:34 | * | rnrwashere quit (Remote host closed the connection) |
| 19:33:56 | * | rnrwashere joined #nim |
| 19:34:47 | skaruts | still giving me errors, I'm gonna just finish what I was doing so that it compiles, and then I'll see about this |
| 19:36:37 | * | Jesin quit (Quit: Leaving) |
| 19:38:34 | shashlick | Araq when can code reordering become the default |
| 19:39:25 | Araq | shashlick, it needs clean separator points and a spec |
| 19:40:14 | Araq | also automatic forwarding proc generation would be sweet |
| 19:40:36 | Araq | but I'm glad to see it seems to work so well for you that you're asking ;-) |
| 19:43:04 | * | rnrwashere quit (Remote host closed the connection) |
| 19:43:14 | shashlick | Yep made recent code changes in feud very easy |
| 19:43:32 | * | Jesin joined #nim |
| 19:49:19 | * | d10n-work quit (Quit: Connection closed for inactivity) |
| 20:09:40 | * | rnrwashere joined #nim |
| 20:11:25 | skaruts | seems to work well for me too, so far (though my code isn't very complex) |
| 20:14:01 | * | rnrwashere quit (Ping timeout: 246 seconds) |
| 20:20:14 | * | rnrwashere joined #nim |
| 20:24:55 | * | rnrwashere quit (Ping timeout: 255 seconds) |
| 20:26:23 | * | solitudesf- joined #nim |
| 20:26:27 | * | solitudesf- quit (Remote host closed the connection) |
| 20:28:30 | * | solitudesf quit (Ping timeout: 250 seconds) |
| 20:29:37 | * | sealmove joined #nim |
| 20:29:54 | sealmove | https://github.com/sealmove/ease any suggestion? what to add? |
| 20:42:01 | * | natrys quit (Quit: natrys) |
| 20:42:13 | shashlick | @sealmove: I don't get the use case for anonymous |
| 20:42:34 | shashlick | Why is a closure not adequate |
| 20:42:41 | * | rnrwashere joined #nim |
| 20:43:11 | sealmove | You want to get a clean namespace |
| 20:43:18 | * | rnrwashere quit (Remote host closed the connection) |
| 20:46:15 | sealmove | You can think of it as a more explicit closure. If you want to use stuff from the enclosing scope, you have to write it explicitly. So if you do it by mistake it's caught. |
| 20:46:49 | sealmove | Also don't have to provide a name. |
| 20:49:56 | sealmove | explicit closure = normal proc, but whatever :P |
| 20:53:26 | * | rnrwashere joined #nim |
| 20:56:39 | * | Vladar quit (Remote host closed the connection) |
| 21:01:42 | rayman22201 | I did not realize gc vs no - gc in Nim would be so controversial... And people do not seem to realize the difference between existence and dereference... geeze... (╯°□°)╯︵ ┻━┻ |
| 21:03:20 | sealmove | Yeah... I saw you answered in the reddit thread. |
| 21:05:24 | rayman22201 | I'm more venting about Varriount on the RFC lol. I have much respect for him, but I disagree with him on this issue strongly :-P |
| 21:06:58 | rayman22201 | I'm all about engaging people on Reddit and such though. communication is key to a good community :-) |
| 21:07:31 | FromGitter | <akavel> Hi! Is there a proc/macro to dump (debug) a value to stdout/err, and still return it as-is? |
| 21:08:09 | FromGitter | <akavel> for example: `some_func(10+dump(7*8/3))` ? |
| 21:08:59 | FromGitter | <akavel> I want to inject it into some somewhat complex expressions. |
| 21:09:10 | FromGitter | <akavel> (To see what's calculated in them.) |
| 21:10:29 | sealmove | Araq: Why is shadowing not prefered in your proposal? Instead of having to write x = nil to free memory. |
| 21:14:22 | * | noeontheend joined #nim |
| 21:15:20 | sealmove | sorry nvm, misunderstood smthing |
| 21:15:49 | rayman22201 | @akavel, nothing built in afaik, but easy enough to write. |
| 21:16:39 | rayman22201 | @sealmove, I was about to say, what would shadowing accomplish here? |
| 21:17:19 | FromGitter | <akavel> rayman22201: I thought I've seen something that dumped AST and value, but maybe I mixed it with something. Or maybe it was an example in some tutorial? Thanks anyway for the reply. |
| 21:18:44 | sealmove | rayman22201: nothing, my bad. I was thinking how Rust doesn't require you to write `dangling = nil`, but that has nothing to do with shadowing, and the real reason is because it forces you to write a whole bunch of lifetime annotation. |
| 21:19:33 | rayman22201 | @akavel, the old macro tutorial had "debugEcho" macro, but that doesn't really do what you want. |
| 21:20:00 | rayman22201 | @sealmove yup. pretty much. |
| 21:20:45 | rayman22201 | There was talk of making a `dispose dangling` sugar macro to make it more obvious what is going on. Since `dangling = nil` is kind of ugly. |
| 21:20:52 | Araq | sealmove, not even lifetime annotations, a 'safe' doubly linked list is impossible with Rust's lifetimes and you're left with workarounds like array indexing or dynamic checks |
| 21:21:28 | sealmove | oh! |
| 21:21:49 | Araq | the examples in my blog post are not randomly chosen |
| 21:22:03 | * | Jesin quit (Quit: Leaving) |
| 21:22:03 | Araq | the show how the model improves over both Rust's and Swift's model |
| 21:22:07 | Araq | *they show |
| 21:22:28 | sealmove | truth is I couldn't understand the doubly linked list example, will try harder ;) |
| 21:23:19 | Araq | dangling = nil may be ugly but it's exactly what needs to happen under the hood |
| 21:23:57 | rayman22201 | I agree. That's why I said *sugar* macro lol. It's definitely just fine, but you can always put lipstick on it :-P |
| 21:24:03 | Araq | we can make it 'disarm dangling' but at this point I don't even want to discuss the syntax |
| 21:24:37 | rayman22201 | fair enough |
| 21:24:58 | * | noeontheend quit (Ping timeout: 250 seconds) |
| 21:25:20 | sealmove | but... in essence, what is the real difference? Um.. I mean, Rust has the concept of owned ref and "borrowed ref", no? |
| 21:25:41 | sealmove | (excuse my ignorance, did read the blog) |
| 21:26:10 | Araq | Rust has a plethora of pointer types, 3 builtin iirc and then 4 in the stdlib |
| 21:27:38 | Araq | the builtins cover unsafe and then unowned and owned but the unowned's lifetime is statically proven and in my proposal it's not. |
| 21:28:21 | sealmove | so... in Rust basically they use a prover but don't codify "owner" in the typesystem? |
| 21:28:32 | Araq | they do |
| 21:30:31 | Araq | the unowned/borrowed pointers have regions attached to them so that they cannot outlive their owners, pretty sweet but the regions use lexical scoping and the point of a heap is to break the lexical scopes |
| 21:31:28 | sealmove | yeah, sounds rational. I remember I couldn't do basic stuff before Rust 2018 because of that. |
| 21:32:07 | sealmove | so Nim will do the same but using a non-lexical scoping approach? |
| 21:32:32 | Araq | that's one way of putting it |
| 21:34:55 | sealmove | okay, guess I'll have to read https://researcher.watson.ibm.com/researcher/files/us-bacon/Dingle07Ownership.pdf as you proposed multiple times. |
| 21:35:54 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 21:36:08 | Araq | Gel is less unproven technology than Rust's lifetimes are, in Gel you can write doubly linked lists, trees with 'parent' pointers etc; all without leaving the "safe subset" or resorting to classical reference counting |
| 21:40:13 | FromGitter | <mratsim> For me I had lots of troube trying to represent a DAG in Rust |
| 21:40:19 | sealmove | "reference counting elimination", is that the catch? |
| 21:40:19 | FromGitter | <mratsim> trouble* |
| 21:40:21 | * | Jesin joined #nim |
| 21:40:56 | FromGitter | <mratsim> I was a programming noob at the time but still. |
| 21:41:41 | FromGitter | <mratsim> To be fair, in Nim I also have a lot of troube representing a DAG without too much GC overhead/genericReset ;) |
| 21:42:21 | sealmove | I stopped believing in Rust's approach some time ago. It's nice but *there has to be a better way* (asking less from programmer) |
| 21:43:03 | FromGitter | <mratsim> The thing with Rust is that it's all or nothing |
| 21:43:28 | FromGitter | <mratsim> you can't gradually opt-in for more security (say once your prototype is proven), you have to get it right from the start |
| 21:44:17 | sealmove | yeah too hardcore, and you pay for it even when you don't need it |
| 21:44:31 | sealmove | which makes it a non-general purpose language |
| 21:44:33 | FromGitter | <mratsim> it's zero cost abstraction though ;) |
| 21:44:40 | FromGitter | <mratsim> (I guess sanity is not a cost) |
| 21:44:45 | sealmove | haha! |
| 21:44:51 | sealmove | nice one |
| 21:45:07 | sealmove | sanity cost abstraction |
| 21:46:12 | FromGitter | <mratsim> Nonetheless kudos to Rust for showing one approach to memory safety that works and basically jumpstarted lots of new research |
| 21:47:02 | Araq | sure but if after a decade of research I need to run a dynamic leak detector over my Rust programs it's quite telling |
| 21:47:40 | sealmove | Point is Rust is selling for more than research. |
| 21:50:37 | FromGitter | <mratsim> I wouldn't go there Araq, Nim has been created a decade ago ;) |
| 21:50:44 | disruptek | it's a rope path up the hill, but there are other avenues of ascent, and the view from the nim side seems more pleasant to me at present. |
| 21:52:39 | Araq | mratsim: Pascal in 1970 was memory safe. you don't offer a 'free' operation, people need to reuse ref objects on their own, no memory safety problems, logical bugs. Ah but Rust with its painful borrow checker is better because it makes you use arrays plus indexing instead which ... is the Pascal solution. |
| 21:59:13 | Araq | mratsim: Nim is older than Rust but it had far fewer resources put into it and it never modeled the heap as a second stack |
| 22:00:28 | Araq | and I tried to do that twice, it's so tempting. |
| 22:00:54 | sealmove | heap as a second stack :D btw question: for system programming Rust uses a lot of unsafe { } code. isn't that an obvious issue too? |
| 22:01:17 | * | narimiran quit (Ping timeout: 245 seconds) |
| 22:01:49 | * | rockcavera quit (Remote host closed the connection) |
| 22:04:52 | Araq | not in my opinion. |
| 22:06:52 | * | krux02 quit (Remote host closed the connection) |
| 22:07:52 | disruptek | Araq: wrt immutability, why can't we ask the list to perform the mutation on the elem? |
| 22:08:13 | disruptek | i mean, automagically. |
| 22:08:18 | Araq | at least they understood that safe code must be allowed to call unsafe code and that unsafe code can call safe code. D has @system and @trusted and @safe and it's terrible IMO. |
| 22:09:58 | Araq | disruptek, it doesn't work well, then you need to say in the signature that 'elem' is reachable from 'head' |
| 22:11:10 | disruptek | it couldn't be abstracted to an alias by the compiler? |
| 22:11:42 | Araq | I haven't thought much about it. How do you think it can work? |
| 22:11:53 | disruptek | oh, maybe i see the problem. hmm. |
| 22:12:24 | Araq | look, there are phases. |
| 22:12:38 | Araq | 1. complex graph is constructed (it's mutable) |
| 22:12:50 | disruptek | put it like this... if the compiler knows how to deny on an immutable pragma, then it should know how to alias it without the pragma, no? |
| 22:12:55 | Araq | 2. complex graph is queried (immutable) |
| 22:13:28 | Araq | what does a type system do? it models the invariants. Mutability is not invariant it's phase dependent. |
| 22:13:43 | Araq | that's why it's so hard to design properly. |
| 22:14:25 | disruptek | i thought it was more like taint. |
| 22:14:56 | FromGitter | <Varriount> Araq: Is it possible to detect possible cyclic data structures using a type graph, at compile time? |
| 22:17:40 | * | I_Right_I joined #nim |
| 22:17:53 | Araq | koch boot -d:release # (134609 lines compiled; 4.595 sec total; 510.93MiB peakmem; Release Build) |
| 22:18:20 | Araq | koch boot -d:release --gc:markAndSweep # (134266 lines compiled; 4.129 sec total; 424.383MiB peakmem; Release Build) |
| 22:19:04 | * | jjido joined #nim |
| 22:20:09 | Araq | koch boot -d:release --gc:boehm # (131783 lines compiled; 3.580 sec total; 325.227MiB; Release Build) |
| 22:20:44 | Araq | notice that the default GC is the RC GC without the cycle collector |
| 22:21:28 | Araq | and that we don't count the RC ops on the stack |
| 22:21:54 | Araq | the problems of RC are not only the cycles |
| 22:22:26 | disruptek | and the graph queries in each phase have to be identical? the query methodology, not the results? |
| 22:22:45 | disruptek | ie. could you have a node reachable via different paths in different phases? |
| 22:23:03 | * | ghidra joined #nim |
| 22:23:07 | Araq | disruptek, it was an abstract example |
| 22:23:29 | disruptek | Araq: i'm okay with that. :-D |
| 22:25:48 | * | solitudesf joined #nim |
| 22:25:49 | Araq | Varriount: the default GC is already the worst for throughput and atomic ops don't help it. Now that maybe ok for when responsiveness matters much more but in the stdlib we don't know the application |
| 22:26:41 | Araq | and the stdlib is a piece of software that you might want to optimize |
| 22:26:48 | FromGitter | <Varriount> Araq: How is the new model going to be faster? It's still going to need to use refcounting, and atomic operations (if threads are used). |
| 22:27:03 | disruptek | no, it doesn't need atomics. |
| 22:27:13 | Araq | we can disable the refcounting, that's how it's faster. |
| 22:27:28 | Araq | ordinary RC cannot be disabled |
| 22:28:23 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 22:28:43 | sealmove | "If a destroyed object has a non-zero reference count, a run-time error occurs and theprogram is terminated" why can't we catch this at compile-time? |
| 22:29:06 | Araq | sealmove, we are going to but I don't know how much of it we can catch |
| 22:29:40 | Araq | and we need to gain experience first to see if it's worth it |
| 22:29:54 | Araq | we lived with dynamic checking for array indexing quite fine |
| 22:30:15 | sealmove | i see |
| 22:30:21 | FromGitter | <Varriount> What I'm trying to get at is this: Couldn't you use a regular refcounting system (something like what Swift uses) and try to detect cyclic data structures at compile time? Then, for cyclic data structures, require extra information (like whether a reference is owned or not). |
| 22:31:53 | Araq | a regular refcounting system that simply ignores the cycles is what Swift does and the performance is so bad that it's like betting on a dead horse |
| 22:32:12 | Araq | ignore the cycle problems. |
| 22:32:22 | Araq | it also has performance problems. |
| 22:33:46 | sealmove | it has to do with ref counting elimination opts? |
| 22:34:29 | * | ghidra quit (Ping timeout: 256 seconds) |
| 22:34:29 | * | skaruts quit (Ping timeout: 256 seconds) |
| 22:36:47 | sealmove | it says Gel "eliminates typically 90% of all counting operations" |
| 22:37:03 | Araq | yes but Gel can only do that in single-threaded mode |
| 22:37:56 | Araq | if I take the risks and introduce this runtime split I might as well care for multi-threading |
| 22:37:58 | FromGitter | <Varriount> I still don't understand how you can just "disable refcounting" in this new model. |
| 22:38:41 | disruptek | it's weaker guarantees; static analysis in debug mode, while release presumes safety. |
| 22:38:53 | FromGitter | <Varriount> Other than by using raw pointers, or risking memory leaks |
| 22:39:43 | * | vjalmr joined #nim |
| 22:39:54 | * | vjalmr left #nim ("Textual IRC Client: www.textualapp.com") |
| 22:40:35 | Araq | every debug run is a weak proof, these add up and problems in production are rare |
| 22:40:55 | * | ghidra joined #nim |
| 22:41:25 | Araq | exactly the runtime model we have lots of experience with. Imperfect but that's the real world here with its compromises. |
| 22:41:36 | disruptek | Araq: have you done anything with klee and nim output? i'm about to get stuck in on that. |
| 22:42:32 | Araq | klee? |
| 22:42:56 | FromGitter | <Varriount> Araq: What are Nim's target use-cases? |
| 22:43:03 | disruptek | it's static analysis for c/++ |
| 22:43:21 | disruptek | http://www.doc.ic.ac.uk/~cristic/papers/klee-osdi-08.pdf |
| 22:43:34 | sealmove | Varriount: wait I have just that Araq quote :)) |
| 22:44:24 | disruptek | this is another good paper on the subject, from last month: https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04A-4_Chau_paper.pdf |
| 22:44:50 | disruptek | sorry, symbolic analysis. dunno why i said static. |
| 22:45:25 | sealmove | "Nim's target audience is the enlightened/misguided programmer who doesn't understand why there should be more than one programming language." |
| 22:45:45 | Araq | Varriount: it's a general purpose programming language where "general purpose" also works when the heap sizes grow. |
| 22:46:12 | Araq | I added a new requirement so that my new runtime makes more sense than the old one. :P |
| 22:46:40 | disruptek | lol |
| 22:46:47 | FromGitter | <Varriount> Araq: And this new runtime will draw in "general purpose" programmers? |
| 22:46:53 | * | al_ joined #nim |
| 22:47:07 | FromGitter | <Varriount> Those that currently use Go, Python, Java, and C#? |
| 22:47:13 | FromGitter | <Varriount> Oh, and Javascript |
| 22:47:28 | disruptek | it will draw in people who are willing to settle for compile-time guarantees over jumping through the rust hoop. |
| 22:47:50 | FromGitter | <Varriount> disruptek: Except that there aren't compile-time guarantees, only runtime ones. |
| 22:47:59 | FromGitter | <Varriount> And even then, that's only in debug mode. |
| 22:48:28 | disruptek | is there a difference? let's just say compilation takes twice as long and call it even. |
| 22:48:34 | Araq | well it's optional, you can leave it on for as long as you want. Just like array indexing |
| 22:48:53 | Araq | Where are your complaints that we don't prove array indexing at compile-time? |
| 22:49:04 | Araq | ah you don't care because not even Rust does that. |
| 22:49:26 | sealmove | Nim can't win in advertising. It can only win in being a better language. The hope is that given time, people will appreciate it and realize the usefulness. |
| 22:49:29 | disruptek | did you see v-lang dude's link to the refutation of iterators in c++? i thought that was pretty interesting. |
| 22:49:30 | FromGitter | <Varriount> Araq: Surprisingly, I don't use arrays or sequences all that much in the software I write. |
| 22:49:45 | FromGitter | <Varriount> And when I do, it's usually looping through them, not accessing random elements. |
| 22:49:59 | disruptek | i mean, it's not his work, but that's where i got turned on to it recently. |
| 22:50:30 | Araq | surprisingly I don't use graphs that often, I use trees and modeling trees with graphs is an abstraction inversion |
| 22:51:16 | disruptek | graphs are incredible to me. |
| 22:51:26 | * | nsf quit (Quit: WeeChat 2.4) |
| 22:51:35 | disruptek | i mean, i believe they exist, but the models their enable are mind-blowing. |
| 22:52:27 | FromGitter | <Varriount> disruptek: There's a difference between getting an error when you compile your production application, and having it crash at 3 in the morning due to a runtime check. |
| 22:52:51 | disruptek | and that's why we don't do runtime checks in production. |
| 22:52:58 | disruptek | logic bugs are your own. |
| 22:53:32 | FromGitter | <Varriount> disruptek: Ok, so you forgo the runtime checks... In this model, that means you then get all the fun of possible memory corruption and data errors. |
| 22:53:47 | disruptek | yes. |
| 22:54:10 | disruptek | the solution to writing better software isn't to pay the penalties for runtime checks every time through the loop. |
| 22:54:24 | disruptek | the solution is to write better tests and then run them before deployment. |
| 22:54:44 | disruptek | let's not guess, y'know? |
| 22:54:50 | disruptek | i mean, are we men or mice? |
| 22:54:52 | Araq | I've seen so many Java programs die with OOM that I don't believe in GCs anymore. |
| 22:55:29 | disruptek | i had a bad experience with java in like '91 and haven't touched it since. |
| 22:55:38 | disruptek | but, graalvm might just bring me back. |
| 22:55:53 | Araq | there were android log statistics, now offline |
| 22:56:04 | Araq | number one bug in Java was NullPointerException |
| 22:56:05 | sealmove | first thing is to get deterministic behaviour, then it's a matter of balance between compile-time guarantees and mental overhead. tests might prove cheaper than having to do lifetime anotation. |
| 22:56:13 | Araq | second bug was Out of memory. |
| 22:56:30 | disruptek | then we give you a way to run the runtime check on demand. |
| 22:56:57 | disruptek | like, at runtime. ya feel? |
| 22:59:05 | * | al_ quit (Quit: al_) |
| 23:02:25 | I_Right_I | Araq: Dare I jump in to agree with you, I am not a big fan of GC's either. |
| 23:02:47 | Araq | Varriount: I might also come up with a 2nd, different proposal of how to evolve Nim's runtime. |
| 23:03:17 | sealmove | when you do `x: owned ref = Foo(); y: owned ref = x` what happens with x? does it downgrade to a regular ref or what? |
| 23:03:36 | Araq | can't you at least see it's totally worth trying? |
| 23:04:33 | disruptek | why would it have to downgrade? |
| 23:04:48 | FromGitter | <Varriount> Araq: I have no doubt that it will work, from a technical perspective. It's the... social perspective that worries me. |
| 23:04:52 | Araq | sealmove, if you access 'x' afterwards it's a static error |
| 23:05:00 | sealmove | disruptek: because can't have 2 owners for the same thing? |
| 23:05:25 | disruptek | oh, i didn't even read the whole snippet. |
| 23:05:30 | sealmove | ok so x is erased from the namespace |
| 23:05:33 | sealmove | great |
| 23:05:45 | disruptek | yeah, that's obviously static. |
| 23:05:49 | Araq | that's not how it's implemented, it uses a control flow graph |
| 23:05:54 | FromGitter | <Varriount> The programmers I know generally don't like having to do any more work than absolutely necessary. |
| 23:06:12 | disruptek | that's the whole point. |
| 23:06:24 | disruptek | to let the computer do the heavy lifting; you just say when. |
| 23:07:11 | disruptek | there's no cost for unowned pointing to owned, too. |
| 23:07:12 | Araq | Varriount: winning these programmers is hard because they also don't want to learn anything new or anything not coming from Big Coorporation |
| 23:07:42 | Araq | or something that hasn't as many libraries as Python. |
| 23:07:49 | * | solitudesf quit (Ping timeout: 255 seconds) |
| 23:08:38 | disruptek | it's like now that the world found python, it's the new yardstick. a yardstick that only measures length, not width, or depth. |
| 23:09:21 | Araq | have you seen how to use Java for Big Data? I have and IMO it's no fun. |
| 23:09:38 | disruptek | i guess the real problem is that there are so few old programmers compared to the number of noobies. |
| 23:10:24 | sealmove | Nim can grow as Python did :)) the long game |
| 23:10:34 | sealmove | good design stacks up |
| 23:10:42 | * | rnrwashere quit (Ping timeout: 250 seconds) |
| 23:11:12 | disruptek | we don't need any more languages north of python; we need more languages closer to the equator, like nim. |
| 23:11:31 | clyybber | Araq: And I'd argue it isn't worth it to win those programmers |
| 23:11:46 | Araq | well we need to grow. |
| 23:12:00 | Araq | and we're doing pretty bad, IMO. |
| 23:12:23 | disruptek | i had no idea that was the case. how do you measure that? google trends? |
| 23:12:46 | Araq | don't want to share the details, sorry. |
| 23:13:07 | disruptek | that makes sense. |
| 23:14:57 | disruptek | i'm not worried. |
| 23:16:08 | * | rnrwashere joined #nim |
| 23:16:39 | sealmove | Nim is big enough already to not go unnoticed when it's totally stable |
| 23:17:47 | Araq | well it's not like we stopped development and are working on this unproven piece of technology because it's more fun |
| 23:17:54 | disruptek | it's just nicer to use. |
| 23:18:18 | ghidra | How granularly could new-runtime be used, i.e. could I depend on a nimble package that uses old runtime? |
| 23:18:34 | disruptek | i don't know about you, but if the community was limited only those who program recreationally, i'd be totally fine with that. |
| 23:18:43 | disruptek | it feels like haskell, that way. |
| 23:19:49 | disruptek | why would you not be able to depend on a previous runtime? |
| 23:19:52 | sealmove | @Araq: This is the game Nim has to win, not advertising, so don't even have second thoughts! |
| 23:20:33 | sealmove | disruptek: no, it's nothing like haskell! |
| 23:21:12 | ghidra | disruptek: Should have been more specific, a nimble package without owned annotations. |
| 23:21:27 | sealmove | it's all for the sake of being more efficient, not for the sake of doing something new |
| 23:22:05 | * | Trustable quit (Remote host closed the connection) |
| 23:22:08 | Araq | ghidra, I don't have a good solution for that, libraries should use 'owned' and your code can continue to use the GC |
| 23:22:26 | Araq | the libraries need to be ported. |
| 23:22:39 | Araq | it's like a Python 2/3 split |
| 23:22:59 | Araq | pretty bad but we have the eternal "not yet v1" excuse |
| 23:27:03 | * | rnrwashere quit (Remote host closed the connection) |
| 23:35:19 | Araq | Varriount: let's assume we can do the "dangling check" at compile-time, always. Would that make you change your mind? Because for me the real negative aspects remain: |
| 23:35:31 | Araq | - breaks code |
| 23:35:47 | Araq | - in rare cases you don't have an ownership tree |
| 23:35:59 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:37:03 | Araq | for me that are the real costs; I already enumerated its advantages. |
| 23:38:12 | FromGitter | <arnetheduck> here we go - first public launch of nimbus beacon chain: have a spin :) https://our.status.im/the-nimbus-mvp-testnet-is-here/ |
| 23:39:55 | Araq | wow, wasn't aware you're so far |
| 23:40:03 | Araq | congrats! |
| 23:44:45 | FromGitter | <arnetheduck> neither were we, but here were are :) |
| 23:49:02 | sealmove | Araq: does this model essentially eliminates the need for multiple ownership? |
| 23:49:50 | Araq | it enforces single ownership |
| 23:50:19 | Araq | well you can always write a SharedPtr[T] with a cycle detector |
| 23:50:21 | sealmove | and since RC is done on normal refs, you can do more with them |
| 23:50:31 | sealmove | oh ok, that would be my next question :) |
| 23:50:54 | Araq | look, my proposal is about what 'ref' should mean, the one thing everywhere in Nim |
| 23:51:06 | Araq | that we don't have many good solutions for |
| 23:52:39 | sealmove | I hope it is the case that porting is just a matter of "strategically placed `owned`s", but I'm afraid it might not... |
| 23:55:31 | Araq | he he |
| 23:57:45 | Araq | if it's not, maybe it's because your program sucks ;-) |