| 00:21:56 | reactormonk | Araq, kwin/kwintoplevel.nim(4, 17) Error: identifier expected, but found '{.' |
| 00:22:04 | reactormonk | alpha*: bool {.importc: "alpha".} |
| 00:22:07 | reactormonk | wrong syntax? |
| 00:23:30 | * | q66 quit (Quit: Quit) |
| 00:46:38 | Araq | reactormonk: alpha* {.importc: "alpha".}: bool |
| 00:47:45 | reactormonk | :-/ |
| 01:47:44 | * | Anaphaxeton quit (Remote host closed the connection) |
| 01:55:28 | reactormonk | NimCopy([{Field0: 0, Field1: cstrToNimstr("Meta+9")}, {Field0: 1, Field1: cstrToNimstr("Meta+8")}, {Field0: 2, Field1: cstrToNimstr("Meta+0")}, {Field0: 3, Field1: cstrToNimstr("Meta+i")}, {Field0: 4, Field1: cstrToNimstr("Meta+p")}, {Field0: 7, Field1: cstrToNimstr("Meta+,")}, {Field0: 5, Field1: cstrToNimstr("Meta+m")}, {Field0: 6, Field1: cstrToNimstr("Meta+.")}], NTI26111); |
| 01:55:32 | reactormonk | why the NimCopy ? |
| 05:00:32 | * | fowl quit (Quit: Leaving) |
| 05:53:05 | * | SchalaZeal joined #nimrod |
| 06:19:45 | SchalaZeal | I'm in a bit of a pickle with my EaselJS wrapper. |
| 06:27:43 | * | Anaphaxeton joined #nimrod |
| 06:29:28 | * | XAMPP-8 joined #nimrod |
| 07:58:30 | * | SchalaZeal quit (Quit: Konversation terminated!) |
| 08:01:16 | * | Araq_ joined #nimrod |
| 08:01:43 | * | Araq_ quit (Client Quit) |
| 08:49:00 | * | XAMPP-8 quit (Ping timeout: 256 seconds) |
| 08:49:31 | * | zahary_ quit (Read error: Operation timed out) |
| 08:54:14 | * | zahary quit (Ping timeout: 252 seconds) |
| 08:59:29 | * | zahary joined #nimrod |
| 10:54:25 | * | Araq_ joined #nimrod |
| 11:02:54 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]) |
| 12:00:52 | * | zahary quit (Ping timeout: 248 seconds) |
| 12:05:57 | * | zahary joined #nimrod |
| 12:13:30 | * | gradha joined #nimrod |
| 12:14:01 | gradha | I can get an untraced reference (ptr) to an object with addr |
| 12:14:09 | gradha | how can I get a traced reference (ref) to an object? |
| 12:14:20 | gradha | s/an object/a variable/ |
| 12:29:23 | * | zahary_ joined #nimrod |
| 12:30:11 | gradha | looks like addr(seq[i]) is not allowed either |
| 12:55:43 | * | gradha quit (Quit: Leaving) |
| 12:59:29 | * | Trix[a]r_za is now known as Trixar_za |
| 13:01:39 | * | zahary1 joined #nimrod |
| 13:01:49 | * | zahary quit (Read error: No route to host) |
| 13:03:09 | * | q66 joined #nimrod |
| 13:23:35 | * | Trixar_za is now known as Trix[a]r_za |
| 15:03:35 | * | gradha joined #nimrod |
| 15:04:53 | * | zahary1 quit (Ping timeout: 248 seconds) |
| 15:06:20 | * | zahary joined #nimrod |
| 16:22:13 | * | Zor quit (Ping timeout: 248 seconds) |
| 16:28:14 | reactormonk | gradha, well, the idea of a traced reference is that you don't fuck with it |
| 16:29:27 | dom96 | gradha: addr(obj)? |
| 16:29:49 | dom96 | If you want a traced reference you need to declare your variable as `ref TObject` |
| 16:30:10 | gradha | so basically its impossible to transform a variable into a traced reference without new+copy? |
| 16:32:25 | gradha | addr(seq[index]) doesn't work, are sequences special or is the []?accessor preventing addr from working? |
| 16:32:58 | dom96 | addr(seq.mget(index)) should work |
| 16:33:19 | dom96 | As far as I know it is impossible. |
| 16:49:20 | * | Zor joined #nimrod |
| 16:55:03 | gradha | I don't think sequences have an mget, the compiler is expecting something from the tables module |
| 16:57:06 | gradha | failed attempt at http://pastebin.com/JWg6EwDg |
| 16:59:10 | gradha | the repr proc showing the address of the variable accessed through [] and addr not willing to return it seems like the compiler is mocking me |
| 17:00:29 | dom96 | hrm |
| 17:01:30 | dom96 | perhaps there is no way to do it. |
| 17:07:10 | * | FreeArtMan joined #nimrod |
| 18:04:34 | * | Trix[a]r_za is now known as Trixar_za |
| 18:39:23 | * | Trixar_za is now known as Trix[a]r_za |
| 18:57:29 | Araq | gradha: my connection is bad tonight |
| 18:57:42 | * | shevy quit (Ping timeout: 256 seconds) |
| 18:58:05 | Araq | indeed you cannot get a 'ref T' without 'new'ing it in the first place |
| 18:58:29 | Araq | and 'addr' does work for seq[i] but not for *parameters* |
| 18:58:48 | Araq | as parameters are readonly |
| 18:59:30 | Araq | for low level stuff this can be annoying, so I thought about allowing it, or adding a paramCast to the language |
| 19:00:02 | Araq | however, 'repr' is written in nimrod so the compiler definitely does not mock you |
| 19:02:04 | gradha | I'm building a TTable over elements passed in as seq, so I have to to make a copy into a local var to be able to use addr on them? |
| 19:02:22 | gradha | a TTable[string, ref object] |
| 19:03:05 | gradha | now I'm simply copying everything by value because its frustrating |
| 19:07:36 | gradha | ok, var param = param it is then |
| 19:10:18 | * | shevy joined #nimrod |
| 19:29:51 | gradha | I want to write a long string literal and don't want to use triple quotes because I don't want line breaks |
| 19:30:13 | gradha | I'm using "a" & "b", is this something that happens at runtime or will the compiler put it together at compile time? |
| 19:30:47 | gradha | sort of like putting two C strings together and let the compiler treat them like a single joined one |
| 19:33:42 | * | FreeArtMan quit (Ping timeout: 240 seconds) |
| 19:36:59 | dom96 | gradha: Yeah, I believe it happens at compile time. |
| 19:37:13 | dom96 | why do you need to use addr on your values? |
| 19:38:59 | gradha | it's an M:N relationship, seems like a waste to copy N more than needed to have M access entries to the table |
| 19:42:38 | * | dom96 isn't really sure what you are doing |
| 19:43:25 | gradha | https://github.com/gradha/argument_parser/blob/master/argument_parser.nim#L64 |
| 19:43:57 | gradha | this version is copying the Tparameter_specification object each time it builds an access in the TTable |
| 19:44:17 | gradha | now I've added "var expected = expected" at the top so I can use addr and avoid the copies |
| 19:50:58 | dom96 | I wonder if that's not equivalent to simply using 'ref TParameter_specification' instead. |
| 19:52:10 | gradha | that would require me to use new() and copy the value into the traced reference when preparing the seq |
| 20:20:05 | * | zahary_ quit (Ping timeout: 252 seconds) |
| 20:23:22 | gradha | looks like "try: let dummy = parse(all_params, @["int test", "-i", "fail"])" is not allowed |
| 20:23:30 | gradha | good thing we have discard() |
| 20:32:49 | gradha | looks like an exception raised inside a template displays an incorrect stack trace, the stack trace contains the correct name of the proc where the template was instantiated, but the line number points to the template's source code rather than the line with the template invokation |
| 20:33:18 | gradha | it makes sense, but could nimrod insert a "false" stack trace with the line where the template is being used? could help debugging |
| 20:37:59 | reactormonk | gradha, file an issue |
| 20:41:45 | reactormonk | Got to admit, I like tk for GUI stuff. |
| 20:42:13 | gradha | from the developer pov or the user pov? |
| 20:42:40 | reactormonk | gradha, developer. And it looks native. |
| 20:44:17 | dom96 | I have always stayed away from tk because it looks crap |
| 20:44:34 | gradha | I was afraid to say that aloud |
| 20:45:15 | reactormonk | dom96, the old tk does |
| 20:47:14 | dom96 | reactormonk: write a nimrod wrapper for it please :P |
| 20:47:26 | gradha | the tk website doesn't have screenshot, and a google image search for the domain only reveals pictures of babies?! |
| 20:47:49 | dom96 | tk the baby UI toolkit |
| 20:48:01 | dom96 | "Fills your screen with babies" |
| 20:48:25 | gradha | seriously http://www.google.es/imgres?q=site:www.tcl.tk+jpg&um=1&hl=es&safe=off&client=safari&tbo=d&rls=en&tbm=isch&tbnid=Th7_Oezof6sjZM:&imgrefurl=http://www.tcl.tk/community/hobbs/carina/set1/&docid=yPLIqaMTjHEuOM&imgurl=http://www.tcl.tk/community/hobbs/carina/set1/carina02.jpg&w=640&h=480&ei=YzUIUeisLofBhAePwoCADg&zoom=1&ved=1t:3588,r:21,s:0,i:167&iact=rc&dur=433&sig=102270266687391989056&page=2&tbnh=185&tbnw=247&start=12&ndsp=16&tx=125&ty=122&biw=1015& |
| 20:48:26 | gradha | bih=784 |
| 20:48:33 | gradha | oh, crap google search link |
| 20:48:34 | gradha | sorry |
| 20:49:11 | gradha | reactormonk: any scren captures of the fresher native look? I've never seen such a thing out of invoking the OS's standard dialog for file operations |
| 20:50:07 | reactormonk | gradha, http://www.tkdocs.com/ |
| 20:50:48 | reactormonk | gradha, http://www.tkdocs.com/tutorial/widgets.html |
| 20:52:34 | dom96 | The Linux screenshots don't look very attractive |
| 20:52:43 | gradha | so it's 8.5 the version with the new featured theme? |
| 20:53:09 | reactormonk | gradha, and use the new widgets. |
| 20:53:18 | reactormonk | aka Tk::Tile |
| 20:53:27 | dom96 | although those docs are pretty nice. |
| 20:53:40 | dom96 | If only gtk had something similar. |
| 20:54:10 | gradha | looking at the individual widget comparisons makes me realize it's not the native look that ends up being distracting but people forcing a style for crossplatforms progs |
| 20:54:31 | gradha | so you end up with a "windowsed" mac/linux version, a "linuxified" windows/mac version, or a "macified" windows/linux version |
| 20:55:17 | gradha | it's a pitty, even the cocoa gtk version of the gimp looked alien on mac, despite using native widgets |
| 20:56:16 | gradha | isn't tk the gui for tcl programs? does it have C bindings or you have to convert to tcl first? |
| 20:57:02 | reactormonk | gradha, it has C bindings |
| 20:57:50 | gradha | searching tkdocs for "C API" or "C bindings" comes up empty |
| 20:58:13 | gradha | they don't advertise their C API much: http://www.tkdocs.com/resources/languages.html |
| 20:59:04 | reactormonk | http://wiki.tcl.tk/2074 |
| 21:01:23 | gradha | ah, so it has to go through tcl first |
| 21:02:45 | reactormonk | the api has a bunch of macros :-/ |
| 21:06:05 | gradha | is there a way to stringify an expr passed into a template for logging? IIRC this would be like ## macros in C |
| 21:06:47 | gradha | consider template test_success(code: expr) {.immediate.} = echo($code) |
| 21:07:04 | gradha | this runs code, and the result of the expression is stringified and outputed |
| 21:07:38 | gradha | could I take "code" and stringify that? kind of like showing the source which was passed into the template |
| 21:10:55 | dom96 | maybe dumpAST or dumpLisp, but that might just echo the 'nkIdent { name = "code" }' |
| 21:26:18 | gradha | so if you are parsing arguments, and a switch requires a value, and there is none, would you prefer an EInvalidValue or EInvalidIndex raised? |
| 21:28:36 | gradha | talking about a commandline switch (aka -s filename), not a language switch/case |
| 21:35:21 | reactormonk | gradha, make your own |
| 21:36:17 | gradha | hehe, let me rephrase then the question: what exception would you like my new one to be inherited from, EInvalidValue or EInvalidIndex? |
| 21:36:51 | gradha | maybe EMissingValue inheriting from EInvalidValue? |
| 21:38:58 | dom96 | hrm, hard question. |
| 21:39:05 | Araq | EInvalidValue |
| 21:40:08 | Araq | oh hey you can read my answers according to the logs :-) |
| 21:40:28 | Araq | well, gradha, using locals and taking their address and putting it to a table is dangerous |
| 21:40:49 | gradha | I know, the pointer outliving the original variable, etc |
| 21:42:15 | Araq | you can move things into tables instead of copying them ... if only tables would support that ... |
| 21:43:00 | Araq | however, I'd use 'ref object' in your API |
| 21:43:18 | gradha | is it more optimal? |
| 21:43:33 | gradha | I'm not interested in any object being "unique" |
| 21:43:42 | Araq | it's what people've come to expect |
| 21:43:44 | gradha | and I don't care about performance too much now |
| 21:44:04 | gradha | yeah, but that's mainstream, not cool enough |
| 21:44:08 | Araq | people can't cope with value types these days anymore anyway |
| 21:45:49 | gradha | besides, I'm doing this mainly for me to learn nimrod, so I don't care too much what others say, and you said values are ok, so I'm going with that |
| 21:46:09 | Araq | did I say that? |
| 21:46:23 | gradha | when I asked about refs |
| 21:47:18 | Araq | well you can also use the copying, it'll be optimized away soon |
| 21:47:38 | Araq | thanks to our groundbreaking TR macro system |
| 21:49:21 | gradha | reactormonk: you said idetools was slow, have you tried recent caas commits? |
| 21:49:35 | reactormonk | gradha, caas? |
| 21:49:49 | gradha | compiler as a service, for idetools |
| 21:49:58 | reactormonk | gradha, doc? |
| 21:50:00 | gradha | or is that not what caas stands for? |
| 21:50:38 | gradha | no idea about docs, zahary commited some stuff yesterday, haven't looked at it myself yet |
| 21:51:13 | Araq | caas = compiler as a service, yeah |
| 21:51:23 | Araq | I'm not sure it's working yet |
| 21:52:39 | gradha | I'm wondering anyway how would that work inside vim/aporia: does the commandline API change or does it require spawning a server and communicating to it through a socket? |
| 21:53:37 | Araq | you start it with 'nimrod serve' and communicate over sockets |
| 21:55:06 | reactormonk | Araq, protocol? SWANK? something else? |
| 21:55:27 | reactormonk | nimrod 9770 tass 3u IPv4 8829854 0t0 TCP *:x11 (LISTEN) |
| 21:55:37 | reactormonk | I assume that one. |
| 21:55:42 | reactormonk | and wtf @ x11 port |
| 21:56:29 | reactormonk | msgs.gErrorMax = high(int) # do not stop after first error |
| 21:56:30 | reactormonk | lol |
| 21:57:08 | Araq | reactormonk: if zahary didn't change it, the protocol is that you pass the command line over the socket |
| 21:57:37 | Araq | and terminated by \n |
| 21:59:14 | zahary | I've also added another mode of operation, where you start a nimrod process and communicate with it over the input/output pipes |
| 21:59:26 | Araq | oh hi zahary |
| 21:59:32 | Araq | I've a list of questions |
| 21:59:35 | Araq | brb |
| 21:59:37 | reactormonk | zahary, \o/ |
| 22:00:16 | reactormonk | zahary, good, gotta rewrite nimrod-mode then to use std/out |
| 22:01:28 | zahary | reactormonk. I noticed your working on the emacs mode, I'll help you as much as I can |
| 22:01:31 | reactormonk | zahary, got me a few docs on pipes so I don't have to guess too much? |
| 22:01:39 | zahary | brb |
| 22:02:05 | reactormonk | zahary, well, I'd prefer a SWANK implementation ;-) |
| 22:07:18 | Araq | zahary: I'm still reviewing all your changes but this is way I've got so far: |
| 22:07:40 | Araq | (1) buckets in idents.nim are safe for caas, no need to ever clear this cache |
| 22:08:22 | Araq | (2) streams: backspace removes the last character? really? which other streams implementation does that? why is it necessary? |
| 22:08:47 | Araq | (3) why export PGeneriqSeq/TGenericSeq? |
| 22:09:42 | Araq | (4) what was the leak in (system/sysstr).setLengthSeq? |
| 22:17:23 | zahary | (1) my extreme measures towards clearing global vars were aimed at hunting the memory leaks. I needed to make absolutely sure that all memory will be reclaimed in the "reset" command |
| 22:19:43 | zahary | (2) I had my doubts about this too, but I never followed through it. I guess, we should revert that, but the problem is that nimrod's standard readLine doesn't behave like the similar functions in other languages which allow basic line editing with backspace |
| 22:20:53 | zahary | (3) sorry about that, I exported it so I can do some nasty casts of GC pointers back to their original types for debugging purposes |
| 22:21:32 | Araq | (2) use -d:useGnuReadline then? |
| 22:22:13 | zahary | as I said standard readline works differently in most languages |
| 22:23:36 | zahary | (4) is the classic leak where a cycle is orphaned through a decref that doesn't perform the full write barrier |
| 22:24:57 | Araq | I don't get why you have to traverse it there |
| 22:25:08 | Araq | just tell the GC what to do with it |
| 22:26:01 | zahary | what do you mean? to call the old forAllChildren(decref)? |
| 22:27:12 | zahary | I've deprecated these flags. only waPush is needed now |
| 22:27:33 | zahary | needed = supported |
| 22:27:44 | Araq | what was wrong with the 'op' parameter anyway? |
| 22:27:53 | reactormonk | zahary, http://web.mit.edu/nelhage/Public/dot-elisp/slime/swank-backend.lisp definterface stuff |
| 22:28:00 | reactormonk | zahary, and http://aemoncannon.github.com/ensime/index.html#tth_sEcC.2 |
| 22:28:26 | zahary | just a quest for speed. no `op` param, no switching in the inner loop |
| 22:29:04 | zahary | I'll remove even the range checks for waPush btw. |
| 22:29:27 | Araq | but the GC is has more code this way |
| 22:29:29 | zahary | you can ensure that the buffer has enough space before entering the marker proc |
| 22:30:45 | zahary | I could see the assembly listing, but I doubt the size impact is significant |
| 22:33:06 | * | XAMPP-8 joined #nimrod |
| 22:34:22 | Araq | switching in the inner loop was free anyway I'd think |
| 22:34:31 | Araq | so easy to predict |
| 22:35:09 | Araq | what's the state of the GC? |
| 22:35:21 | Araq | I see things like: |
| 22:35:24 | Araq | template pseudoRecursion(typ: TRecursionType, body: stmt): stmt = |
| 22:35:25 | Araq | # |
| 22:38:05 | zahary | I wanted to make all these loops prettier :) I'll make one more commit for tidying things up |
| 22:38:05 | zahary | otherwise, if you noticed my reset command, after executing it now, the compiler frees all the allocated memory |
| 22:38:58 | gradha | does nimrod support a platform where high(int) != high(biggestInt)? if so, which? |
| 22:39:20 | Araq | gradha: any 32bit system for instance |
| 22:39:30 | zahary | reactormonk, does swank cover all the idetools commands. does it have "find references"? |
| 22:40:53 | Araq | zahary: why was it necessary to change markStackAndRegisters? |
| 22:41:21 | zahary | what is changed about it? the new stack top? |
| 22:41:41 | gradha | ah, can't compile with --cpu:i386 because of nimbase.h:484:28: error: 'assert_numbits' |
| 22:41:46 | reactormonk | zahary, any interest in adding swank as interface? |
| 22:42:00 | Araq | you mark the jmpbug in an extra loop |
| 22:42:06 | Araq | *jmpbuf |
| 22:42:15 | zahary | yeah, see my notes around setStackTop |
| 22:43:04 | Araq | I read them |
| 22:43:36 | zahary | so, isn't the problem clear? |
| 22:43:38 | Araq | what's that to do with ... oh I get it |
| 22:43:51 | Araq | sweet :-) |
| 22:43:54 | reactormonk | zahary, ensime got that command |
| 22:45:10 | zahary | reactormonk, I promise at least to look through the spec more carefully. you can easily implement an adaptor for any protocol externally btw |
| 22:45:13 | reactormonk | zahary, swank:uses-of-symbol-at-point |
| 22:45:41 | zahary | ah, thanks, didn't see in the first glance |
| 22:50:21 | gradha | given that I can't convert expr in a template to a string, is there any variable holding the curren source's file line I could log? |
| 22:51:12 | gradha | just like C's __FILE__ __LINE__ defines |
| 22:51:39 | Araq | gradha: you can do that but I forgot how ;-) |
| 22:51:57 | Araq | for the __FILE__ stuff check out how system.assert does it |
| 22:52:22 | gradha | {.line.} pragma |
| 22:53:30 | gradha | oh, magical InstantiationInfo |
| 22:55:03 | Araq | oh magical 'astToStr' :P |
| 22:55:48 | gradha | oh, magical irc |
| 22:55:59 | gradha | where were you in the past? |
| 22:56:34 | gradha | awesome, it works |
| 23:00:09 | Araq | zahary: I don't get your write barrier |
| 23:00:20 | Araq | you still perform inplace RC updates |
| 23:00:35 | Araq | and .. oh wait |
| 23:00:37 | Araq | never mind |
| 23:01:31 | Araq | however the old GC was concerned about memory usage for an excessive cycleRoots sequence |
| 23:02:03 | Araq | which is why I left it as a hash table of bitsets |
| 23:02:36 | gradha | muahaha, thanks for making nimrod, it's really cool |
| 23:02:37 | Araq | the papers suggest to use a fixed size buffer for cycleRoots and perform a collection when it's full |
| 23:02:59 | Araq | gradha: a bit late for that ... :P |
| 23:03:11 | Araq | but you're welcome |
| 23:03:55 | Araq | but I really dislike the write barrier triggering a GC |
| 23:04:24 | zahary | erm, I haven't looked carefully at the hash table code, but are you suggesting that it uses less memory than an array? |
| 23:04:34 | Araq | yes |
| 23:04:43 | Araq | you keep saying it's a hash table |
| 23:04:45 | zahary | hmm, got to take a look at this :) |
| 23:04:47 | Araq | it's not |
| 23:04:53 | Araq | it's mostly a bitset |
| 23:06:29 | Araq | but traversing it should surely be slower than an array |
| 23:06:31 | zahary | hmm, indeed I was fouled. I have such a vivid memory of reading some hash table code somewhere, hmm :) |
| 23:07:28 | zahary | ah. there you go. CellSetGet - this looks a lot like hash table |
| 23:09:28 | Araq | look at the elements iterator |
| 23:11:16 | Araq | it's a hash table of bit sets and yeah the expensive part is the hash table lookup |
| 23:12:25 | Araq | however the first access should be successful |
| 23:12:39 | zahary | but what is a bitset in this context? some kind of trie? how does it manage to compress memory? |
| 23:12:39 | Araq | and then there is 1 additional memory access for the bit test |
| 23:13:32 | Araq | there is a bit reserved for every word in a page |
| 23:14:07 | zahary | ok, so if you need to remember some pointer, you raise its bit? |
| 23:14:30 | Araq | yeah |
| 23:14:43 | Araq | and the next pointer will likely be in the same page |
| 23:14:57 | * | gradha quit (Quit: Leaving) |
| 23:15:00 | Araq | in fact, during traversal it optimizes for page-based access |
| 23:15:41 | Araq | page is some random block size btw |
| 23:15:49 | Araq | it doesn't have to match the OS's page size |
| 23:16:17 | zahary | I see, clever. I never measure the memory consumption aspect as it never occurred to me it was saving memory, but the iteration speed in marking and freeing cycle roots is quite improved with arrays (2x I think) |
| 23:16:54 | zahary | I also removed any uses of incl and excl |
| 23:17:14 | Araq | yeah cellsets are now only used for repr I think |
| 23:17:39 | Araq | the cycle collector was not only wrong |
| 23:18:08 | Araq | it was also optimized for code size and few runtime memory usage |
| 23:18:27 | Araq | 3 passes over a graph are slow anyway |
| 23:18:34 | Araq | so I never optimized it |
| 23:19:04 | Araq | and benchmarks never showed it being a bottleneck |
| 23:19:13 | Araq | now we know why, of course ;-) |
| 23:21:50 | zahary | btw, did you read my latest notes about the memory safety of retired buffers. this problem refuses to go away :/ |
| 23:22:14 | Araq | the comment in setLengthSeq? |
| 23:22:18 | zahary | yes |
| 23:23:54 | Araq | why is it still a problem if you don't dealloc in growObj anyway? |
| 23:26:15 | zahary | the problematic situation is when the sequence is shrunk |
| 23:26:38 | zahary | let x = sq[10] |
| 23:26:39 | zahary | sq.setLen(4) |
| 23:27:19 | Araq | ah yeah |
| 23:27:30 | Araq | well it's sort of an edge case |
| 23:27:44 | Araq | we could not free anything in the old slots |
| 23:27:45 | zahary | the question is whether we have "crashes-free" mode |
| 23:28:02 | Araq | then we leak there until the sequence is recycled |
| 23:28:09 | Araq | or the slots are overwritten again |
| 23:28:50 | zahary | ok, we won't free the slots, but should we run the destructor of sq[10]. then x points to a destroyed object |
| 23:30:29 | zahary | obviously the code is broken and at some point we must refuse to support it, but the question is what kind of curruption/crash safety guarantees are possible |
| 23:31:01 | zahary | think about it. I'll have to wake up early in the morning tomorrow, good night |
| 23:31:05 | Araq | we shouldn't conflate 'setLen' and 'shrink' |
| 23:31:21 | Araq | shrink should free and be unsafe, setlen is faster and leaking |
| 23:31:31 | Araq | dunno yet about the destructor issue |
| 23:31:38 | Araq | will think about that |
| 23:31:58 | Araq | good night |