| 00:00:17 | apotheon | I'm not so sure it's all *that* easy to speed up Ruby. Part of the reason it's slow is all the ungodly heaps of dynamic stuff it does. |
| 00:00:38 | apotheon | Essentially *anything* can change at runtime. |
| 00:01:17 | fowl | <- wants to write a ruby implementation in nimrod >_> |
| 00:01:42 | Araq | fowl: what do you need a preprocessor for? you know about #def ... |
| 00:02:10 | apotheon | fowl: Doo eet. |
| 00:02:13 | apotheon | I'd like to see that. |
| 00:02:35 | apotheon | It'd actually probably be easier to take inspiration from Rubinius to do that than from YARV. |
| 00:03:20 | apotheon | fowl: Write a Python implementation in Nimrod. |
| 00:08:30 | fowl | Araq: because some macros need to be expanded to parse correctly |
| 00:09:21 | Araq | fowl: that's what #def does ... |
| 00:10:45 | fowl | ok then ill just make it use #def for complex #defines |
| 00:14:14 | Araq | maybe I should have implemented a heuristic if to handle #define as #def or #define |
| 01:08:08 | * | q66 quit (Remote host closed the connection) |
| 01:23:41 | NimBot | Araq/Nimrod 399b3db Araq [+0 ±1 -0]: optimized evals.nim a bit |
| 02:36:17 | * | erlnoob joined #nimrod |
| 02:36:23 | erlnoob | hello |
| 02:39:32 | reactormonk | erlnoob, hey |
| 02:39:57 | reactormonk | erlnoob, most of the activity is during CET, but I'm here around CT |
| 02:41:17 | erlnoob | hi new to nimrod, so far so good -- just following along the tutorial -- but there's a slight omission in the download page, it should mention something like "ln -s $your_install_dir/lib /usr/lib/nimrod" |
| 02:41:35 | erlnoob | it shouldn't be a problem, just for completeness sake :) |
| 02:43:30 | fowl | erlnoob: that is not necessary |
| 02:44:27 | fowl | unless you're on freebsd |
| 02:44:32 | fowl | maybe |
| 02:46:07 | erlnoob | fowl i'm on osx... i only did ln -s the binary and got a warning on my first compile |
| 02:46:41 | fowl | oo ok |
| 02:46:54 | reactormonk | erlnoob, editing PATH should be enough. |
| 02:47:45 | erlnoob | yea the problem is fixed, just thought to mention it here :) |
| 02:48:29 | reactormonk | erlnoob, https://github.com/Araq/Nimrod/blob/master/doc/tut1.txt |
| 02:48:44 | reactormonk | feel free to edit |
| 02:51:55 | erlnoob | cool |
| 02:53:45 | reactormonk | erlnoob, I'll accept your PR if it makes sense - if Araq doesn't like it at all, he can still revert it. |
| 03:24:18 | * | ccssnet quit (Quit: http://atccss.net) |
| 03:25:11 | * | ccssnet joined #nimrod |
| 03:53:22 | reactormonk | erlnoob, not interested? :-( |
| 03:54:00 | erlnoob | interested, will probably push a PR later in the day if that's ok |
| 03:54:18 | reactormonk | erlnoob, that's totally fine, I'll sleep soon |
| 03:54:27 | erlnoob | ok thanks for your help |
| 03:58:10 | * | ccssnet left #nimrod ("http://atccss.net") |
| 06:26:07 | * | erlnoob quit (Quit: erlnoob) |
| 07:02:54 | * | zahary1 joined #nimrod |
| 08:58:52 | * | zahary1 quit (Read error: Operation timed out) |
| 09:13:21 | * | zahary1 joined #nimrod |
| 10:20:38 | JStoker | dom96: About the nimrod article you're writing, https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nimrod_(programming_language) is pretty obviously saying more non-primary sources (as that isn't exactly independent)... So, does nimrod have any use outside nimrod-code.org? :p |
| 10:23:38 | dom96 | Yeah, that may be a problem. We don't really have any non-primary sources. |
| 10:24:00 | dom96 | But i've seen programming language articles with even less references and they are still alive. |
| 10:24:11 | dom96 | So I will argue with them this time :P |
| 10:27:10 | * | q66 joined #nimrod |
| 10:48:44 | NimBot | nimrod-code/nimbuild bc69fc2 Dominik Picheta [+0 ±3 -0]: Builder: permissions are now applied to uploaded files. |
| 10:49:22 | JStoker | Such as? |
| 10:49:42 | JStoker | It doesn't matter the quantity of the references, if they're all from the same source |
| 10:51:03 | dom96 | http://en.wikipedia.org/wiki/Visual_Prolog |
| 10:51:08 | dom96 | Doesn't even have any references |
| 10:52:17 | * | zahary1 quit (Quit: Leaving.) |
| 10:53:34 | dom96 | http://en.wikipedia.org/wiki/Claire_%28programming_language%29 |
| 10:53:36 | dom96 | Same with that |
| 10:55:22 | JStoker | Just because others do it, doesn't mean you should? ;p |
| 10:55:40 | Araq | we can easily set up another URL not starting with nimrod-code.org and have a 2nd source :P |
| 10:55:45 | JStoker | ... xD |
| 10:56:20 | JStoker | As long as it's not content written by the 'core developers', that's probably fine |
| 10:56:30 | dom96 | Maybe I should start linking to discussions about Nimrod on forums and such. |
| 11:03:39 | dom96 | But I already have some references which link to websites outside of nimrod-code.org |
| 11:03:51 | dom96 | and I just added a reference to a stack overflow question |
| 11:15:58 | * | Araq wonders how macros.nestList could ever have worked in the first place ... |
| 11:18:50 | dom96 | hrm, someone should create some cool pattern matching macro. |
| 11:29:32 | Araq | dom96: do it |
| 11:29:46 | dom96 | I don't have timeeee |
| 12:02:59 | dom96 | haha, a Portuguese version of the Nimrod article still exists: http://pt.wikipedia.org/wiki/Nimrod_%28linguagem_de_programa%C3%A7%C3%A3o%29 |
| 12:03:51 | Araq | ah that's why we have so many people from Portugal here :-) |
| 12:12:25 | NimBot | Araq/Nimrod 6a040dd Araq [+0 ±2 -0]: bugfix evals.nim |
| 12:38:21 | NimBot | nimrod-code/nimbuild 4d4ff56 Dominik Picheta [+0 ±1 -0]: Builder: Bugfix: Streams belonging to a process should not be freed. |
| 12:40:55 | NimBot | Araq/Nimrod 8c28d37 Dominik Picheta [+0 ±1 -0]: A file stream now makes sure to only close its file descriptor once. |
| 12:50:27 | * | zahary1 joined #nimrod |
| 13:52:50 | * | gradha joined #nimrod |
| 14:20:29 | gradha | amazing http://stackoverflow.com/a/6807599/172690 did anybody know about $XDG_DATA_HOME/Trash ? |
| 14:51:25 | dom96 | nope |
| 14:52:41 | fowl | i dont have it |
| 14:53:07 | gradha | are you using a desktop? |
| 14:53:38 | fowl | yes xfce |
| 14:53:51 | gradha | maybe it lacks certification? |
| 14:56:26 | dom96 | same here: it's not set to anything |
| 15:01:43 | fowl | apparently my trash is at Trash:/// -_- |
| 15:02:39 | fowl | oh its at ~/.local/share/Trash/files |
| 15:05:19 | gradha | how do you go from Trash:/// to ~/.local/share/Trash/files? |
| 15:06:01 | fowl | i read it on SO then i touched a file in ~/.local/share/Trash/files to see if it would come up in in trash:/// and it did |
| 15:07:22 | dom96 | I have .Trash-1000 folders on each partition |
| 15:07:49 | gradha | 1000 sounds like your uid, on macosx mine is 501 |
| 15:08:39 | fowl | yea i have .Trash-1000s on my other partitions too |
| 15:29:27 | * | gradha quit (Ping timeout: 260 seconds) |
| 15:31:35 | * | gradha joined #nimrod |
| 16:43:04 | * | zahary1 quit (Read error: Connection reset by peer) |
| 16:43:34 | * | zahary1 joined #nimrod |
| 16:47:29 | * | xcombelle joined #nimrod |
| 16:49:57 | gradha | amazing, the forum rss actually works |
| 16:59:33 | Araq | ugh gradha |
| 16:59:51 | Araq | do you recall what we discussed about the standalone except statement? |
| 16:59:59 | gradha | I'm answering that |
| 17:00:01 | Araq | you wanted to improve its docs iirc ... ;-) |
| 17:00:08 | Araq | oh alright |
| 17:00:22 | gradha | IIRC except was without type |
| 17:00:35 | Araq | yes |
| 17:00:48 | Araq | it can be read as 'on error do' |
| 17:01:18 | Araq | or wrapped in a template/macro |
| 17:28:27 | * | fowl quit (Ping timeout: 260 seconds) |
| 17:30:18 | gradha | does something like bash send-process-to-background aka & exist in nimrod? I guess I could create a daemon thread and let it do something for a while before dying |
| 17:31:55 | * | fowl joined #nimrod |
| 17:38:21 | Araq | hrm you can create a background thread that spawns a process via osproc |
| 17:38:35 | Araq | not sure you need that thread |
| 17:39:02 | gradha | yes, processes all the way |
| 17:39:51 | gradha | it seems I have to actually wait in my process for an OS sound to complete before I can exit, otherwise the sound is not heard |
| 17:40:19 | gradha | I was expecting the OS to already provide a sort of deamon like process for these kind of sounds, at least it does so on iOS |
| 17:43:23 | gradha | no fork in nimrod? |
| 17:44:49 | gradha | oh yes, posix module |
| 17:44:57 | gradha | nice docs |
| 17:45:37 | Araq | hmm are you sure you want to use fork directly? |
| 17:45:56 | Araq | osproc is the wrapper you're supposed to use instead |
| 17:45:56 | gradha | sure |
| 17:46:11 | gradha | I don't need to run another process, I need to run myself in the background |
| 17:46:39 | Araq | sounds unportable :P |
| 17:46:52 | gradha | well, it's all "when defined(macosx)" so I don't care |
| 17:47:19 | gradha | and I'm using hardcoded paths like /System/Library/Components/CoreAudio.component/Contents/SharedSupport/SystemSounds/dock/drag to trash.aif |
| 17:47:28 | gradha | that's not even protable across macosx versions |
| 17:48:14 | gradha | I'll leave the recycle bin portability to real men using real operative systems when I release the module |
| 17:48:47 | gradha | hah, where's gour when you need him |
| 17:49:09 | Araq | gour uses Ada now ;-) |
| 17:49:33 | gradha | did read some nice things about ada at http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html |
| 17:49:48 | Araq | I have no idea why, its UI situation is worse than Nimrod's fwiw |
| 17:50:35 | gradha | I love the haskell ones |
| 17:50:45 | gradha | makes me wanna learn haskell |
| 18:05:36 | * | fowl quit (Ping timeout: 264 seconds) |
| 18:06:22 | * | fowl joined #nimrod |
| 18:20:44 | * | zahary1 quit (Quit: Leaving.) |
| 18:23:18 | * | zahary1 joined #nimrod |
| 18:24:19 | gradha | I found out what my yesterday's "nimcache weird" claims actually were: https://github.com/Araq/Nimrod/issues/379 |
| 18:59:30 | dom96 | woo 111 watchers |
| 19:00:16 | Araq | dom96: yeah I noticed |
| 19:00:24 | Araq | all thanks to HN |
| 19:00:31 | dom96 | :D |
| 19:00:58 | dom96 | So what else does the wiki article need before I submit it? |
| 19:01:01 | dom96 | I want to submit it ASAP |
| 19:03:06 | Araq | I thought you wanted to link to my blog ... |
| 19:03:56 | dom96 | *shrug* |
| 19:04:07 | Araq | don't shrug me :P |
| 19:04:26 | * | dom96 begins to shrug repeatedly |
| 19:04:28 | Araq | shrugging off is only allowed for dictators here |
| 19:05:07 | dom96 | That's not fair :( |
| 19:05:40 | Araq | Quod licet Iovi, non licet bovi :P |
| 19:06:05 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 19:06:12 | dom96 | Anyway, please answer my question :P |
| 19:06:29 | Araq | which question? |
| 19:06:36 | dom96 | <dom96> So what else does the wiki article need before I submit it? |
| 19:06:39 | gradha | I look away for a moment and you are speaking about jon bon jovi? |
| 19:07:10 | gradha | Araq: where's your blog |
| 19:07:22 | Araq | gradha: here's the German version for you: Wenn zwei das gleiche tun, ist es noch lange nicht dasselbe. |
| 19:07:37 | Araq | dom96: a link to my blog? |
| 19:08:01 | dom96 | Araq: Here is a Polish version for you: Nie mam pojęcia oczym ty pierdolisz :P |
| 19:08:05 | gradha | auch wenn zwei nichts machen? |
| 19:08:26 | Araq | gradha: dann erst recht ;-) |
| 19:08:41 | dom96 | Araq: Hurry up with the blog then. |
| 19:09:11 | Araq | dom96: ok |
| 19:09:37 | gradha | dom96: just for reference, mama huevo is badly spelled slang for "suck balls" |
| 19:10:48 | dom96 | gradha: Yeah, glad I kicked him. Any ideas what is up with these spanish people? |
| 19:11:00 | gradha | no idea, I prefer to not talk to any |
| 19:17:05 | Araq | gradha: yeah spanish girls have too much body hair ... |
| 19:17:50 | Araq | which they never shave |
| 19:18:57 | gradha | hair is so practical to fend of the hot summer though |
| 19:22:13 | gradha | awww... something sigsevs when I call my objc native function from a forked process |
| 19:30:17 | Araq | ping zahary |
| 19:32:38 | zahary1 | hi Araq, I'm chasing the rod files crash |
| 19:33:10 | Araq | thanks but I wanted to ask where the destructor tests are hiding |
| 19:33:27 | Araq | or do we have none? |
| 19:35:12 | zahary1 | hmm, maybe I never added tests to the test suite |
| 19:36:51 | Araq | alright, I'm adding tests then |
| 19:37:27 | Araq | I still think they are full of problems btw |
| 19:38:06 | zahary1 | besides the temp var handling? |
| 19:38:09 | Araq | in C++ they can be optimized away even though they can have side effects |
| 19:38:20 | Araq | yes besides implementation issues |
| 19:39:05 | zahary1 | copies can be optimized away, not destructors |
| 19:39:26 | Araq | hmm yeah |
| 19:40:08 | Araq | takeOwnerShip(createObj()) |
| 19:40:31 | Araq | # destructor called for the createObj call? |
| 19:41:28 | zahary1 | well, in C++ a real takeOwnership proc will accept a heap address |
| 19:42:08 | zahary1 | so the question is a bit bogus, but yes, there will be a destructor call here |
| 19:42:26 | Araq | F# uses 'use x = expr' vs. 'let x = expr' and only for 'use' the destructor is invoked at the scope exit |
| 19:43:06 | zahary1 | well, this is the IDisposable interface from C# (using blocks), right? |
| 19:43:12 | Araq | right |
| 19:43:22 | Araq | but it doesn't matter, does it? |
| 19:43:48 | zahary1 | it has similar purpose, but I don't see your point |
| 19:44:45 | Araq | well I think it's a good compromise to only call the destructor in the let/var x = expr context |
| 19:45:05 | zahary1 | as I have argued before, the C++ way of RAII is bit more useful when you have composite objects made of other destructable parts |
| 19:45:48 | Araq | but I'm talking about 'let x = expr' vs. p(expr) contexts here |
| 19:46:05 | zahary1 | you can make the responsibility of the called function to destroy the object |
| 19:46:49 | Araq | the problem is: sometimes you want to take ownership, sometimes you don't |
| 19:47:02 | Araq | p(expr) can mean both |
| 19:47:06 | zahary1 | that would be semantically similar to the C++ behavior. otherwise, the semantics are just broken (not calling the destructor at all) |
| 19:47:54 | Araq | well I'm implementing a check that forbids p(expr) if expr has an attached destructor |
| 19:47:54 | zahary1 | yes, I guess that requires 2 compiled versions of p which is not nice |
| 19:48:16 | zahary1 | that may be a reasonable compromise |
| 19:48:36 | Araq | yeah that's what I thought |
| 19:48:46 | Araq | turns out, it's not so easy ;-) |
| 19:48:53 | Araq | proc destruct(o: var TMyObj) {.destructor.} = |
| 19:48:54 | Araq | if o.p != nil: dealloc o.p |
| 19:49:08 | Araq | --> "Error: usage of a type with a destructor in a non destructible context" |
| 19:49:24 | Araq | for the 'o.p' part |
| 19:50:44 | Araq | so it mustn't trigger for parameters |
| 19:50:58 | Araq | I wonder what's the rule here |
| 19:51:08 | zahary1 | but why does it trigger here? which variable is a temp? |
| 19:51:36 | Araq | I guess I need to attach it to nkCall ;-) |
| 19:51:38 | zahary1 | I think the rule is just "a temp variable cannot have a destructor" |
| 19:51:58 | Araq | there are no explicit temp variables in semexprs though |
| 19:52:49 | zahary1 | yes, but it's easy to write isTemp(expr) proc |
| 19:53:18 | Araq | really? how does it look like? ;-) that's what I'm wondering |
| 19:54:07 | zahary1 | it's either a proc call that returns a value (not var, ref, etc) or a constructor expression |
| 19:55:07 | Araq | alright |
| 19:55:50 | Araq | proc open: TMyObj = |
| 19:55:51 | Araq | result = TMyObj(x: 1, y: 2, p: alloc(3)) |
| 19:55:55 | Araq | # oops ;-) |
| 19:56:27 | Araq | it's valid if it escapes :P |
| 19:56:38 | Araq | otherwise you can't write constructors |
| 19:57:46 | Araq | but I can fix that too |
| 19:58:05 | Araq | well I think this rule is a good compromise for 0.9.2 |
| 19:58:16 | Araq | but for later versions I think it's crappy |
| 19:58:31 | zahary1 | so why would it trigger here? it's also valid for var x = TMyObj(…) so it must be checked only in param positions |
| 19:59:12 | Araq | yeah ok, but var/let already got special treatment |
| 19:59:13 | zahary1 | why don't you try the rewrite-to-let-location approach? only the interaction with term rewriting scare you? |
| 19:59:36 | Araq | it's easier to create an error message then rewriting it properly |
| 19:59:57 | Araq | and your "only check in param positions" is wrong: |
| 20:00:13 | Araq | if TMyObj(...): # invalid too |
| 20:00:39 | Araq | unless an if condition context is a param position for you ;-) |
| 20:00:55 | zahary1 | true |
| 20:01:29 | zahary1 | but still there are finite number expressions that can produce a destructable temp variable |
| 20:04:16 | Araq | hmm, what about 'x.o = TMyObj()' |
| 20:04:42 | Araq | it's valid if 'x' is result, invalid otherwise? |
| 20:05:12 | Araq | but that's wrong anyway: |
| 20:05:29 | Araq | while true: result.x = TMyObj() # leaks |
| 20:06:29 | zahary1 | that's in place construction of the x variable (C++ will destroy the temp var in practice, but the situation in theory can be handled with something like RVO) |
| 20:06:52 | Araq | how the hell got C++ away with attaching it to a type anyway, I still think it needs to be attached to a constructor |
| 20:07:16 | zahary1 | so TMyOBj gets the lifetime of the x variable (which is in turn bound to the lifetime of the result) |
| 20:08:46 | Araq | attaching it to a constructor makes much more sense: var f: TFile = autoOpen("file.txt") |
| 20:09:03 | zahary1 | I don't follow your argument. what's wrong with attaching it to the type in this situation? I explained why attaching it to the type is superior in composite objects so I'm not convinced about the GO way of doing it |
| 20:09:31 | Araq | Go does it differently than what I propose |
| 20:09:52 | zahary1 | var f = open("file.txt") # RVO makes sure that f is the only constructed object here |
| 20:10:13 | Araq | but often you want to do: |
| 20:10:45 | Araq | p(f) where p takes ownership and thus it shouldn't be closed |
| 20:11:15 | zahary1 | takes ownership of what? the resources inside the File object? |
| 20:11:24 | Araq | the File object |
| 20:11:25 | zahary1 | or the object itself |
| 20:11:32 | Araq | of the object itself |
| 20:11:41 | zahary1 | well, how can it take ownership when the object is passed by value? |
| 20:12:05 | Araq | ok, files are not the best example here |
| 20:12:29 | Araq | construct a tree and it makes lots of sense |
| 20:13:03 | Araq | at the end you can have an: let x = createTree(...) and it will free the tree |
| 20:13:09 | Araq | at scope end |
| 20:13:35 | Araq | you can always do this with a wrapper type of course |
| 20:14:16 | Araq | however destructors undo construction so they should be tied to those imho |
| 20:14:56 | zahary1 | now, if I wrote a destructor for the tree I probably had some reason to prefer this behavior. there are pointers to tree that don't have destructors, all kinds of shared ownership smart pointers, etc |
| 20:15:29 | zahary1 | what is different in this example if you tie destructors to constructors? |
| 20:15:57 | Araq | that you can have procs that construct subtrees without any attached destructor |
| 20:16:00 | zahary1 | createTree is such a constructor? there is another one that doesn't destroy the object? |
| 20:16:08 | Araq | exactly |
| 20:16:31 | zahary1 | well, that's what smart pointers are for |
| 20:16:59 | Araq | tying them to constructors had however some problems wrt dynamic control flow iirc: |
| 20:17:22 | Araq | let x = if cond: ctorWithDtor() else: ctorWithoutDtor() |
| 20:18:17 | zahary1 | again, smart pointers work better for composite objects and so on. you can build things out of them |
| 20:19:50 | zahary1 | finally, if you just like the idea of a function that registers a "destroy" side effect in the current scope, this is very easy to do with type-bound destructors and templates |
| 20:20:41 | Araq | alright alright, lets get back to the while true: result.x = TMyObj() problem |
| 20:21:11 | zahary1 | template myDestuctorInjectingProc(x, y): expr = let r = SomeImplemention(x, y); finally: destroy r; r |
| 20:22:17 | Araq | that kind of misses the point though |
| 20:22:40 | Araq | we have quite some types that expose a 'close' proc now |
| 20:23:05 | Araq | adding an 'autoOpen' proc is nicer than providing wrapper types but ymmv |
| 20:25:46 | zahary1 | we should migrate the more important types to proper destructable definitions as this haves more benefits long-term, but otherwise a general-purpose "with/using" template could be useful |
| 20:26:01 | zahary1 | but ok, let's go back the previous issue |
| 20:28:18 | Araq | well I think for now we should disallow it too |
| 20:28:51 | Araq | it's however a problem: |
| 20:29:02 | Araq | while true: result = TMyObj() |
| 20:29:17 | Araq | we said the assignment to 'result' is special and allows object construction |
| 20:29:58 | Araq | however we wouldn't generate any destructor call for it, so the example would leak :-/ |
| 20:30:34 | Araq | so we're back to requiring flow analysis |
| 20:31:07 | Araq | in fact, no need for a loop here: result = TMyObj(); result = TMyObj() has the problem already |
| 20:31:15 | zahary1 | well, this example requires more complete value semantics to work properly |
| 20:32:06 | zahary1 | but let's look at it with a real destructable type like TFile |
| 20:32:06 | zahary1 | for i in 1..10: result.file = openFile("foo" & i & ".txt") |
| 20:32:19 | zahary1 | obviously, you want to open 10 files here and to close them |
| 20:33:20 | zahary1 | so for this to work, you must either have overriding of the `=` operator, where you'll close the currently open file in result.file |
| 20:33:48 | Araq | overriding of = operator is on my todo anyway already |
| 20:34:17 | zahary1 | or you must have some kind of scheme, where you have copy constructors that ref-count on some underlying resouce handle |
| 20:35:08 | Araq | anyway it's simple to hack around for now :-) I'll only allow it in 'return' not in 'result =' ;-) |
| 20:36:24 | zahary1 | btw, I've previously asked for placement new. we need it for implementing some custom memory allocation schemes like arenas, etc |
| 20:36:53 | zahary1 | it requires a magic that exposes the codegen construction calling scheme |
| 20:37:07 | Araq | not sure what you mean |
| 20:37:42 | zahary1 | var memory = malloc(sizeof TFoo) |
| 20:37:56 | zahary1 | memory <—TFoo(x: 10, y: 20) |
| 20:38:04 | Araq | you can already overload 'new' for a user defined type |
| 20:38:15 | zahary1 | this constructs TFoo inside the memory I provided |
| 20:39:09 | Araq | well that doesn't even work with the builtin new for now I think |
| 20:40:14 | zahary1 | so we need a patch that implements both :) |
| 20:40:40 | Araq | yeah I wanted to optimize 'new' further |
| 20:40:59 | Araq | however the new constructors don't help here |
| 20:41:17 | Araq | as they are mapped to system.new in the backend when it's too late |
| 20:42:08 | zahary1 | this can work with a bit more type safe interface too. I suggest that we add a type called TMemSlot[T], TLocation, TStorage[T], etc. the placement new operator will allow only construction of the proper type |
| 20:42:08 | Araq | you'd want to transform it to 'new' in the fronted so overloading of 'new' works |
| 20:42:59 | Araq | oh it's already restricted to 'ref T' |
| 20:43:31 | zahary1 | I'm calling the feature "placement new", because that's how it's called in C++ |
| 20:43:43 | Araq | I noticed ;-) |
| 20:43:53 | zahary1 | there is no relation to the managed heap allocation function 'new' |
| 20:44:25 | Araq | arguably placement new is only necessary because of the special 'new' syntax in C++, right? |
| 20:44:59 | zahary1 | not really. as you see, we need it here in order to be able to implement custom allocation scheme |
| 20:45:46 | zahary1 | you may argue the other way around. that the special new syntax was invented, because of the need for placement new |
| 20:46:35 | zahary1 | the fundamental operation is "construct this object over this raw memory" |
| 20:47:32 | zahary1 | the new operator in C++ performs allocation and then executes this fundamentally required operation |
| 20:47:41 | zahary1 | placement new skips the allocation part |
| 20:47:56 | zahary1 | … (in C++) |
| 20:50:58 | zahary1 | custom_new(TFoo(x: 10, y: 20)); in nimrod could be implemented like this: template custom_new(constuction: expr): expr = custom_alloc(sizeof(construction)) <— construction |
| 20:51:51 | Araq | with a magic <-- operator? |
| 20:51:57 | zahary1 | yes |
| 20:52:25 | Araq | not sure we need it |
| 20:52:57 | Araq | you can also pass 'construction' to a proc via a 'var' param |
| 20:53:26 | Araq | in fact, I'm not sure how this inplace construction can work in C++ |
| 20:53:43 | Araq | you need to rewrite the 'construction' expression |
| 20:54:07 | Araq | otherwise you end up with some final memcopy into the dest |
| 20:54:35 | zahary1 | this is about the location where the object will be constructed (the RVO address in the constructor function) |
| 20:56:50 | zahary1 | var x = MakeFoo(1, 2) is translated to MakeFoo(1, 2, &x); |
| 20:56:50 | zahary1 | memory <— MakeFoo(1, 2) is translated to MakeFoo(1, 2, memory); |
| 20:57:23 | Araq | looks like a rather simple TR macro to me |
| 20:58:27 | zahary1 | argh, what is missing is this codegen magic that takes care of the hidden last parameter of the construction function |
| 21:01:55 | Araq | I still can't follow you. What's so special about custom_new(TFoo(...)) in the first place? |
| 21:02:48 | Araq | where is the advantage over newFoo(...) ? |
| 21:05:38 | zahary1 | the goal is to be able to support custom allocation schemes as said (arenas, our per-frame bump-pointer allocator, etc) |
| 21:07:23 | zahary1 | so you want to be able to construct objects will not POD value semantics over the raw memory that your custom allocation scheme will provide |
| 21:07:43 | Araq | the problem is though: if I have an initFoo(): TFoo proc it's too late already |
| 21:08:04 | zahary1 | it's not. memory <— initFoo() does the right thing |
| 21:08:15 | Araq | it can't |
| 21:08:21 | zahary1 | why not? |
| 21:08:44 | Araq | unless initFoo has been compiled as initFoo(x: var TFoo) in the first place |
| 21:09:04 | zahary1 | well, it is compiled like this if it's a struct type |
| 21:09:22 | Araq | it is? who says that? :-) |
| 21:09:27 | zahary1 | I mean in the codegen |
| 21:09:34 | zahary1 | that's the return-value-optimization |
| 21:10:35 | Araq | don't tell that the guys who special cased complex numbers to be returned in 2 registers |
| 21:11:00 | Araq | but I see |
| 21:11:27 | Araq | you define the ABI so that it works this way |
| 21:11:55 | zahary1 | types returned in 2 registers are POD types almost by definition |
| 21:12:20 | zahary1 | so you can have a little less optimal copying placement operator for them |
| 21:12:30 | Araq | hrm I overread that POD part in your answer |
| 21:20:21 | Araq | btw there is now a rod file reader, compile rodread as a main program |
| 21:26:27 | zahary1 | yes, I'm using it already |
| 21:26:48 | zahary1 | btw, the problem was not related to the file id changes as I hoped for |
| 21:27:24 | Araq | no but only because I fixed that already |
| 21:27:28 | zahary1 | the reader itself crashes when trying to print the system.nim rodfile. the crash is very early in the data section on the bool enum definition |
| 21:27:45 | Araq | I know |
| 21:28:07 | Araq | the problem is that somehow SystemModule points to the wrong symbol I think |
| 21:28:32 | Araq | so systemModule.tab refers to some wrong table |
| 21:29:10 | zahary1 | I was going to step in through the parsing of the enum there, does it reference system.nim somehow (the bool enum?) |
| 21:29:51 | Araq | it loads the 'bool' type twice; however the second loading returns another pointer |
| 21:30:19 | Araq | both have the same ID though |
| 21:30:29 | Araq | and the rodfile is consistent I think |
| 21:31:00 | NimBot | Araq/Nimrod 6f1adf6 Zahary Karadjov [+0 ±2 -0]: use file IDs consistently instead of file paths in the rod files handling |
| 21:31:09 | Araq | my bet is that we have 2 system module PSym |
| 21:31:36 | Araq | and SystemModule points to the wrong one |
| 21:31:44 | Araq | I mean magicsys.SystemModule |
| 21:31:44 | zahary1 | hmm, I guess you are referring to the loadStub crash when you try to recompile a simple module like hallo.nim |
| 21:31:51 | Araq | yes |
| 21:32:01 | zahary1 | try running rodread on the system.rod itself |
| 21:32:08 | zahary1 | it crashes too (no loadStub there) |
| 21:32:09 | Araq | I did |
| 21:32:18 | Araq | worked for me the last time |
| 21:32:29 | Araq | I tried tests/rodfile/aconv though |
| 21:32:38 | zahary1 | hmm, try debug version of rodread |
| 21:33:09 | Araq | using file ids instead of file paths is wrong btw |
| 21:33:19 | Araq | so I changed that back |
| 21:33:29 | zahary1 | I'm not writing them inside the rod file |
| 21:33:43 | zahary1 | just a minor optimization in the in-memory data |
| 21:34:00 | zahary1 | and less calls to fileInfoIdx which is a bit expensive |
| 21:34:33 | dom96 | hrm, is there a reason why the docs for the unittest module are not generated? |
| 21:35:11 | Araq | dom96: check if unittest is listed in web/nimrod.ini |
| 21:35:34 | dom96 | Looking at the source of the module the exported procedures don't really have much documentation... |
| 21:35:58 | Araq | well it's missing in nimrod.ini, so that's why |
| 21:37:04 | dom96 | yes, well I know that much. |
| 21:37:28 | Araq | well that means we forgot to add it |
| 21:39:58 | Araq | we should really do: 'type TFileIdx = distinct int32' btw |
| 21:42:34 | zahary1 | there is such a type, but I avoid adding new imports and int32 remained in quite a few places so I gave up using it |
| 21:43:06 | Araq | that's sad :-) |
| 21:43:36 | Araq | the lineinfo stuff needs to cut out of msgs.nim and then adding this import is fine |
| 21:57:11 | Araq | let x = open() |
| 21:57:19 | Araq | Error: for a 'var' type a variable needs to be passed |
| 21:57:35 | Araq | hrm |
| 21:57:44 | Araq | people may not like that |
| 21:58:03 | Araq | the problem is that the destructor expects a 'var T' |
| 21:58:23 | Araq | and you can't pass a let to a var T |
| 21:58:25 | zahary1 | that's not mandatory I think |
| 21:58:57 | Araq | what do you mean? |
| 21:59:08 | Araq | it's fine to enforce var x = open() here? |
| 21:59:59 | Araq | btw your transformation is not triggered for global statements but I guess that's fine |
| 22:00:00 | zahary1 | I meant, technically it's possible to define destructor not taking a var param, but I agree that would be strange and I see your point in the example |
| 22:01:15 | Araq | *shrug* it would introduce a special case in the language, so I won't do anything about it |
| 22:01:38 | Araq | it's fine the compiler enforces it to be 'var' for me |
| 22:01:53 | zahary1 | it's not big deal, yes |
| 22:02:10 | * | Trix[a]r_za is now known as Trixar_za |
| 22:03:35 | * | gradha_ joined #nimrod |
| 22:03:39 | * | gradha quit (Read error: Connection reset by peer) |
| 22:05:33 | zahary1 | I'm falling asleep and I'll be heading to bed. btw there are some other tests that fail inexplicably on my machine. they have passed fine on nimbuild |
| 22:05:58 | Araq | yeah, it keeps aporia from compiling on macosx |
| 22:06:33 | Araq | you're on mac, right? |
| 22:06:39 | zahary1 | yep |
| 22:06:52 | Araq | yes it's very strange |
| 22:07:06 | Araq | on mac sometimes a yield statement is not eliminated |
| 22:07:09 | zahary1 | the default GC now is v1 with the fixes, right? |
| 22:07:37 | Araq | yes but it leaks for the compiler due to wrong 'acyclic' annotations |
| 22:07:59 | Araq | --gc:markAndSweep should work fine now |
| 22:08:08 | zahary1 | I suspect some kind of premature free was happening with my GC (and by extension with the same fixes applied to v1) |
| 22:08:15 | * | gradha_ quit (Ping timeout: 252 seconds) |
| 22:08:49 | Araq | I don't know |
| 22:09:04 | Araq | your stack handling changes looked correct and yet triggered a crash too |
| 22:09:49 | * | gradha joined #nimrod |
| 22:10:11 | zahary1 | anyway, good night for now |
| 22:10:18 | Araq | wait a sec |
| 22:10:28 | Araq | what's the error message for the rodfile reader? |
| 22:11:14 | zahary1 | it complains that the decodeInt proc encountered an invalid character |
| 22:11:29 | zahary1 | rodread.nim(1175) rodread |
| 22:11:29 | zahary1 | rodread.nim(1144) viewFile |
| 22:11:29 | zahary1 | rodread.nim(368) decodeSym |
| 22:11:29 | zahary1 | rodutils.nim(103) decodeVInt |
| 22:11:29 | zahary1 | system.nim(2448) hiddenRaiseAssert |
| 22:11:29 | zahary1 | system.nim(2440) raiseAssert |
| 22:11:30 | zahary1 | Error: unhandled exception: contains({'a'..'z', 'A'..'Z', '0'..'9', '-', '\x80'..'\xFF'}, s[i]) [EAssertionFailed] |
| 22:11:30 | zahary1 | ➜ |
| 22:11:43 | zahary1 | and that's somewhere inside the bool enum |
| 22:12:02 | Araq | are you it's no version problem? |
| 22:12:42 | zahary1 | let me check one final time, but I deleted the rod files quite a lot of time |
| 22:12:57 | Araq | old rod files don't work with the viewer |
| 22:13:21 | Araq | hm but then it has some version checking |
| 22:13:32 | zahary1 | yep, fails with a fresh rod file |
| 22:13:49 | Araq | I'm quite sure I tested it in debug |
| 22:13:51 | zahary1 | works for you in debug rodreader? |
| 22:14:30 | * | gradha quit (Ping timeout: 264 seconds) |
| 22:14:33 | Araq | let me check again |
| 22:16:50 | Araq | now it says: Error: cannot open file (or maybe wrong version) |
| 22:16:57 | * | gradha joined #nimrod |
| 22:17:12 | zahary1 | well, I bumped the version |
| 22:17:12 | Araq | but it used to work ;-) |
| 22:17:28 | Araq | well I have not applied your changes here |
| 22:17:35 | Araq | and it's a fresh rod file anyway |
| 22:17:58 | zahary1 | now such an error is even more weird |
| 22:20:24 | Araq | it also shouldn't be 569KB |
| 22:20:44 | Araq | though maybe my memory is failing me and system.rod always was this large |
| 22:21:09 | zahary1 | mine is 545KB so I guess that's ok |
| 22:21:34 | Araq | now where is my hex editor ... |
| 22:22:10 | zahary1 | I'll look for mine under the pillow :) see you tomorrow |
| 22:22:48 | Araq | alright good night |
| 22:31:32 | NimBot | Araq/Nimrod 05f69db Araq [+0 ±1 -0]: bugfix: lambdalifting needs to deep copy parameters |
| 22:31:32 | NimBot | Araq/Nimrod 0f37cb5 Araq [+2 ±4 -0]: improvements for destructors |
| 22:31:32 | NimBot | Araq/Nimrod 0560be7 Araq [+0 ±3 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 22:33:10 | * | zahary1 quit (Quit: Leaving.) |
| 22:43:21 | Araq | zahary: I was wrong, I already checked out your code and so the version was wrong; now I get the same error as you and rodread fails |
| 22:57:00 | * | Trixar_za is now known as Trix[a]r_za |
| 23:04:57 | * | Trix[a]r_za is now known as Trixar_za |
| 23:05:49 | dom96 | yay more nimrod repos by gradha |
| 23:06:12 | * | dom96 lols at all the kpop |
| 23:06:28 | gradha | come on, it's serious stuff! |
| 23:06:39 | gradha | look at all those wikipedia pages, just wish nimrod had so much |
| 23:07:12 | dom96 | huh, Seohyun is very young. |
| 23:07:33 | gradha | in kpop all girls start underage |
| 23:07:44 | gradha | you see, they have to use their time, since being 25 is like being a grandma |
| 23:08:13 | gradha | boys start also underage, but who cares about boys anyway |
| 23:08:30 | dom96 | I cannot contain my laughter "But that would be really raw, like asking Jessica to eat a cucumber (she dislikes them!)." hahah |
| 23:09:15 | dom96 | If only all software readmes were this awesome, everyone would be a software developer. |
| 23:09:48 | gradha | I try to tell that myself every day |
| 23:10:11 | Araq | who would want that? everybody a software dev? omg. |
| 23:10:37 | gradha | indeed, we would not have kpop then, only dubstep or metal |
| 23:13:34 | dom96 | omg there are so many of these kpop girls! |
| 23:13:57 | gradha | and that's only one group |
| 23:16:59 | * | Mathnerd626 quit (Read error: Connection reset by peer) |
| 23:18:28 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 23:24:39 | * | Mathnerd626 joined #nimrod |
| 23:33:55 | * | q66 quit (Remote host closed the connection) |