| 00:05:02 | * | q66 quit (Quit: Quit) |
| 11:52:52 | * | Araq_ joined #nimrod |
| 12:02:35 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]) |
| 13:56:21 | * | Vladar joined #nimrod |
| 14:40:36 | * | FreeArtMan joined #nimrod |
| 14:41:05 | * | q66 joined #nimrod |
| 15:12:36 | * | exhu joined #nimrod |
| 15:12:58 | exhu | hi all! |
| 15:15:06 | exhu | does anyone know how to iterate over object fields? |
| 15:35:17 | * | exhu quit (Quit: Leaving) |
| 17:00:33 | dom96 | Araq: Brilliant job on including what exceptions are raised by a proc in the docs. I love this feature. |
| 17:00:42 | dom96 | (I would still love to be able to document it though :P) |
| 17:02:00 | dom96 | Also some of them raise E_Base which looks puzzling |
| 17:41:04 | * | Trix[a]r_za is now known as Trixar_za |
| 17:41:04 | * | FlutterAi is now known as Nimrod |
| 17:46:48 | Araq | dom96: true ... |
| 17:47:01 | Araq | you can list the exceptions explicitly too btw |
| 17:47:08 | dom96 | mm, I know. |
| 17:48:39 | dom96 | But yeah, brilliant job nonetheless :D |
| 17:48:43 | Araq | thanks |
| 17:49:01 | Araq | still some bugs left ... why does it still list some exceptions twice? |
| 17:49:09 | Araq | very strange ... |
| 17:49:18 | Trixar_za | Btw Araq, I had a weird bug |
| 17:49:33 | Araq | Trixar_za: I'm listening |
| 17:50:08 | dom96 | Why can't I do: proc a() = var x = 9 div 0; proc b() {.raises: [].} = a() |
| 17:50:10 | Trixar_za | I have two sections, IRC and IM and I had a channel key in both. If I tried to reading the second channel key's value, it always gave me a error |
| 17:50:13 | dom96 | (All on one line?) |
| 17:50:22 | Trixar_za | But when I changed the first channel to chan, suddenly it worked |
| 17:51:27 | Araq | well what error? |
| 17:51:36 | Araq | dom96: because it's bad style :P |
| 17:51:55 | dom96 | Araq: true :P |
| 17:53:21 | Trixar_za | Error: unhandled exception: value is not accessible [EInvalidField] |
| 17:55:05 | Araq | Trixar_za: you're using it wrong then ;-) |
| 17:55:09 | Trixar_za | It's weird, because I change the other channel key to chan, so works with the same line of code and same line in the conf file after the change. |
| 17:55:47 | Araq | hrm, provide a gist then please |
| 18:00:26 | Trixar_za | https://gist.github.com/4126530 |
| 18:00:39 | zahary | Araq, should we keep the LLVM code? I'm making some reforms concerning the rope caches and have the opportunity to clean it up |
| 18:01:19 | Araq | zahary: I'm torn but often end up deleting it ;-) |
| 18:02:40 | zahary | do you happen to know what are the most common hits for the rope cache? |
| 18:03:02 | Trixar_za | Actually the test work |
| 18:03:04 | Trixar_za | hmmm |
| 18:03:17 | zahary | I made compile-time formatting macros for ropes and hoisting function that caches ropes in global vars |
| 18:03:32 | zahary | but still, the rope cache prevails with 95% efficiency :) |
| 18:03:52 | Araq | Trixar_za: if currentSection == section and currentKey == key: |
| 18:03:54 | Araq | return e.value |
| 18:04:11 | Trixar_za | No wait, it fails |
| 18:04:20 | Araq | this doesn't validate you have a 'cfgKeyValuePair' and thus 'e.value' may not be accessible |
| 18:04:24 | Trixar_za | I forgot to change my conf file |
| 18:05:07 | Araq | zahary: the cache is only used for leaves anyway iirc |
| 18:05:10 | Trixar_za | if e.kind == cfgSectionStart: currentSection = e.section |
| 18:05:11 | Trixar_za | if e.kind == cfgKeyValuePair: currentKey = e.key |
| 18:06:18 | zahary | not really as I have already killed around 200K of cache hits |
| 18:07:12 | zahary | but anyway, I'll investigate further - I can just clean it between compilations as an alternative |
| 18:07:33 | Trixar_za | Still doesn't explains why changing the name of the first 'channel' fixes the reading of the second one. Also why doesn't it fail for the other similar name keys? |
| 18:13:27 | Araq | Trixar_za: sorry your program logic looks wrong :P |
| 18:13:42 | Trixar_za | Probably is :P |
| 18:13:55 | Araq | lines 17-18 need to be protected by the check in line 16 |
| 18:13:56 | Trixar_za | Mind you |
| 18:14:10 | Araq | and what's wrong with 'elif' or a 'case' statement anyway? |
| 18:14:11 | Trixar_za | I don't really need the second channel for the imbot |
| 18:14:23 | Trixar_za | There is a built in default for bitlbee servers |
| 18:14:58 | Trixar_za | Yes, but how to you check a case of the final if statement? |
| 18:16:16 | Araq | meh, just have a look at how nimweb does it |
| 18:17:51 | Trixar_za | I would comment how we need better examples, but I tend not to read them :P |
| 18:19:41 | Trixar_za | That reminds me |
| 18:19:47 | Trixar_za | I need to setup a test contact |
| 18:26:56 | Araq | dom96: it lists 'E_Base' whenever it can't compute the proper exception list |
| 18:27:13 | Araq | [E_Base] means "maybe some exception" |
| 18:32:05 | dom96 | I see |
| 18:33:52 | Araq | zahary: I think we have a serious problem if the compiler starts using macros ... |
| 18:34:19 | Araq | the problem is that the TNodeKind enum is kept binary compatible with the enum in macros.nim |
| 18:35:10 | zahary | I've kept the interface compatible, it can be switched on and off |
| 18:35:22 | Araq | great |
| 18:35:42 | Araq | I had the same problem with the TMagic stuff |
| 18:35:52 | Araq | so I needed to change that to string comparisons |
| 18:55:10 | * | FreeArtMan quit (Ping timeout: 246 seconds) |
| 18:55:43 | Araq | oh btw zahary, I solved the code generation for multi dispatch this morning |
| 18:56:29 | * | ekselkiu joined #nimrod |
| 18:57:01 | Araq | got it down to an indirect jump and some easily predicted comparisons |
| 18:57:39 | Araq | if the object type are mostly static at runtime, that is ... |
| 18:57:41 | * | TheVoid joined #nimrod |
| 18:58:10 | Araq | GCC's computed gotos are really nice for this feature though :-) |
| 18:59:16 | Vladar | Does anybody know how to send nil instead of pointer to imported (importc) function? Got SIGSEGV at compiling time. |
| 18:59:40 | Araq | welcome TheVoid |
| 18:59:53 | Araq | Vladar: sigsegv at compile time is a compiler bug ... |
| 19:08:05 | Vladar | and same on newest build =( |
| 19:08:51 | Araq | Vladar: bug report |
| 19:09:19 | Vladar | yep, in progress |
| 19:10:35 | Araq | zahary: have a look please: https://gist.github.com/4126968 |
| 19:13:52 | Vladar | Araq, just checking, `pointer` type is analogue to `void *` in c? |
| 19:14:04 | Araq | yes |
| 19:21:50 | zahary | hrm, you're counting on the fact that the method will be reentered with the same types? |
| 19:22:18 | * | exhu joined #nimrod |
| 19:22:37 | exhu | !ping |
| 19:22:37 | NimBot | pong |
| 19:22:37 | NimBot_ | pong |
| 19:22:50 | exhu | two bots -) |
| 19:24:01 | exhu | need some help, are there nimrod gurus? |
| 19:26:01 | Araq | zahary: yes |
| 19:26:04 | Araq | hi exhu |
| 19:26:13 | exhu | hi Araq |
| 19:26:36 | zahary | this technique is called inline polymorphic caches and some script languages use it, but why can't we assign static IDs as we've talked before? |
| 19:27:08 | Araq | I know how it's called :P |
| 19:27:31 | zahary | and then just use a normal switch. I'm thinking about DLLs now |
| 19:27:31 | exhu | Araq, should I consider typeinfo module incomplete? |
| 19:27:36 | Araq | static IDs look harder to do and don't play nice with DLLs |
| 19:27:49 | Araq | I'm answering on the forum |
| 19:28:00 | Araq | the answer is yes, I forgot that one ;-) |
| 19:28:10 | Araq | it's easy to implement though, I can tell you how |
| 19:28:30 | zahary | you remember what I proposed for depth-first traversal of the hierarchy and the baseId variable for DLLs, right? |
| 19:28:58 | Araq | yeah but it's more complicated :P |
| 19:29:45 | Araq | and I'm not sure your solution really works with MI |
| 19:30:04 | zahary | MI? multiple inheritance? |
| 19:30:15 | Araq | my solution is simple and very flexible as it allows 'of' to be as expensive as we want to |
| 19:30:28 | Araq | (yeah multiple inheritance) |
| 19:31:29 | zahary | PIC sends you in the land of dynamic languages - they are fast these days, but I think any static solution will be more efficient |
| 19:32:04 | Vladar | Araq, nevermind, nil pointer is not a cause. |
| 19:32:21 | zahary | in dynamic langauges you get "mostly the same types", because functions are not polymorphic in nature |
| 19:32:28 | Araq | Vladar: if the compiler segfaults, it segfaults and it's a serious bug |
| 19:32:29 | zahary | but methods are by definition polymorphic |
| 19:32:37 | zahary | "most functions are not polymorphic in nature" |
| 19:33:41 | Vladar | Araq, yeah, but I want to figure out real cause before sending bugreport. |
| 19:33:44 | Araq | damn you stop raising good points ... I'm happy it's possible without JIT or instruction patching |
| 19:34:53 | Araq | but fine I won't implement it and you can implement your way |
| 19:36:31 | Araq | exhu: what does 'baseTypeKind' return for you? |
| 19:38:57 | Araq | zahary: my thinking was that for the collide example most of the time the same types collide so PIC should be fine |
| 19:38:58 | exhu | akObject |
| 19:39:24 | zahary | if you want to try implementing it, that's not a problem for me. I can always look at the generated code, try another approach, see which works better, etc |
| 19:40:13 | exhu | Araq, typeinfo function "fields" enumerates only fields of the type specified, it won't return inherited fields |
| 19:40:36 | zahary | collide, you mean physical simulation? |
| 19:42:00 | Araq | yeah well I mean that often you have some 80%+ distribution |
| 19:42:20 | exhu | Araq, i thought to go with macros then it looked terribly complex to me and i found typeinfo rtti to be more appropriate. |
| 19:42:23 | Araq | where 80% of your objects are of the same type and you have few of an inherited type |
| 19:43:14 | Araq | PIC should work fine for these cases |
| 19:43:27 | zahary | since I indeed care for the performance of collide, in C++ one would implement it like this: colliderFunc[(shape1.type << TYPES_BITS) & shape2.type)] (shape1, shape2) |
| 19:43:27 | Araq | exhu: add this code to typeinfo.nim please: |
| 19:43:56 | zahary | there are many ways to implement multi-methods and for me it would even make sense to have a pragma that specifies the implementation |
| 19:44:25 | Araq | proc base*(x: TAny): TAny = |
| 19:44:27 | Araq | result.rawType = x.rawType.base |
| 19:44:28 | Araq | result.value = x.value |
| 19:44:50 | Araq | and exhu your approach with 'fields' + recursion looks really good |
| 19:48:53 | Araq | Vladar: you can use --verbosity:3 to determine what input the compiler crashes |
| 19:50:07 | exhu | Araq, thanks. I'll make a pull request after i test it all. |
| 19:50:09 | Vladar | Araq, thanks, I already figured it out: it's crashes when accessing const tuple of unsigned integers |
| 19:50:54 | Vladar | Araq, https://github.com/Araq/Nimrod/issues/259 |
| 19:51:36 | Araq | exhu: maybe you need to substract some offset of 'x.value'; still thinking about it, I don't think it's necessary |
| 19:51:49 | Vladar | It's ok with ints or floats, but not with uints |
| 19:52:24 | Araq | yay ... |
| 20:02:34 | Araq | Vladar: here you go |
| 20:02:58 | exhu | Araq, how to get a String representing the name of the type of a variable and/or a typedesc? |
| 20:05:01 | exhu | Araq, good to have proc typeName(a: TAny): String or so |
| 20:05:53 | * | Nimrod needs to disable highlights for this channel :P or make his highlight a litttttle more specific. |
| 20:06:21 | Araq | Nimrod: change your nick :P |
| 20:07:02 | Araq | you can do T.type.name I think to get the typename at compiletime for a generic type T |
| 20:07:38 | Araq | but the RTTI doesn't even contain object names ... so how could it provide it? ;-) |
| 20:07:39 | Nimrod | Araq: but but |
| 20:07:44 | exhu | i'd better add a proc name*(x: TAny): string |
| 20:07:48 | Nimrod | I've been using this nick for months |
| 20:07:57 | Nimrod | :P |
| 20:08:04 | Araq | Nimrod is older :P |
| 20:08:08 | Nimrod | I'm sure it is |
| 20:10:27 | Araq | exhu: and yeah this means you can't load a class by name ... |
| 20:11:18 | exhu | i don't need to load a class by name, i prefer my own class factory if i need to. |
| 20:11:53 | Araq | then typeinfo should be good enough for you |
| 20:12:10 | exhu | i saw there's type name stored in TNimType.node.name. Now i can't convert it to cstring, as compiler crashes with SIGSEGV on $node.name |
| 20:12:27 | exhu | from cstring to string |
| 20:13:17 | Araq | node.name is a field name I think |
| 20:14:10 | exhu | yes, it's TAny.rawType.node.name, and that name is a cstring |
| 20:14:46 | Araq | why does that crash the compiler? |
| 20:14:58 | Araq | what's wrong today? |
| 20:15:53 | Vladar | Araq, I just tried fresh build with this fix, but it still crashes |
| 20:16:20 | Araq | it compiled and produced correct output for me, Vladar |
| 20:16:40 | Vladar | hmm... strange |
| 20:16:57 | exhu | Araq, sorry it's not compiler, it's the test program itself -) |
| 20:17:41 | Araq | that means node.name is nil :P |
| 20:19:53 | Araq | Vladar: check that 'nimrod -v' has the date of today |
| 20:21:09 | exhu | Arag, so there's no way to check for type at runtime, i.e. to get type name? |
| 20:22:11 | exhu | Araq, i mean the name of object type |
| 20:22:22 | Vladar | 2012-11-18. I don't get it, I just pulled fresh .zif from github and that commit is there |
| 20:22:28 | Vladar | *.zip |
| 20:23:58 | Araq | exhu: as I said you can get it compile-time and can setup some lookup table to have this information at runtime, but nimrod's own RTTI does not contain any type names |
| 20:24:26 | Araq | Vladar: you need to bootstrap |
| 20:26:14 | exhu | Araq, ok thanks a lot! I think i have all i need now. |
| 20:35:00 | Vladar | Araq, thanks, it works now. |
| 20:35:08 | Araq | great |
| 20:40:07 | * | Trixar_za is now known as Trix[a]r_za |
| 20:44:49 | Araq | btw what are you working on, exhu? |
| 20:48:09 | exhu | Araq, trying to implement a simple standalone database application to grab filesystem trees and let users organize it with tags, previews etc. a media catalogue. |
| 20:49:05 | Araq | do you use an existing database backend? |
| 20:49:27 | exhu | i have family photos on CDs and external drives, and some old family home videos digitized from VHS. They are spread between external hard drives and CDs |
| 20:49:38 | exhu | I use sqlite3 |
| 20:49:52 | reactormonk | for storing the photos? |
| 20:50:09 | exhu | not the photos but only descriptions or previews |
| 20:50:32 | exhu | with tags, text documents, electronic books etc. |
| 20:52:49 | Araq | exhu: I'm puzzled by your 'raises: [EDb, EDb]' fragment |
| 20:53:11 | Araq | do you use 2 different database backends in this example? |
| 20:53:47 | Araq | I added code to prevent double listing of the same exception type ... |
| 20:56:08 | exhu | you can reproduce with https://github.com/exhu/Palitsa/blob/master/nimrod/palitsa_db.nim |
| 20:56:25 | exhu | i import db_sqlite |
| 20:56:41 | exhu | which probably imports sqlite3 bindings |
| 20:59:03 | Araq | sorry, I'm a bit lazy; did you use the latest compiler and 'doc2'? |
| 21:02:34 | Vladar | Araq, I also posted about 'multiple definition' errors with new (after 0.9.0) builds: https://github.com/Araq/Nimrod/issues/261 |
| 21:02:36 | exhu | 0.9.1, yes just recompiled with koch |
| 21:03:58 | exhu | nimrod doc2 also produces a lot of error messages like "lib/pure/os.nim(1383,69) Error: can have an unlisted effect: FReadIO" |
| 21:04:10 | Araq | Vladar: yeah fowl has the same problem ... haven't looked into it yet |
| 21:04:53 | Araq | well that explains it, exhu ;-) |
| 21:05:00 | Araq | are you on windows? |
| 21:06:05 | exhu | i'm on linux x64 |
| 21:12:51 | Vladar | what is the best way to send/recieve struct from imported function: object or tuple? |
| 21:13:24 | Araq | object |
| 21:14:09 | Araq | Vladar: I downloaded nimgame but dunno how to compile it :P |
| 21:14:43 | Vladar | Araq, just create main file with one string: import common, engine |
| 21:15:13 | Vladar | and then: nimrod c -p:lib this_file.nim |
| 21:15:38 | Araq | ok |
| 21:15:42 | Vladar | Araq, any pragmas for that object? {.final.} or something else? |
| 21:15:55 | Araq | not with 0.9.0 |
| 21:16:00 | Araq | maybe 'bycopy' |
| 21:16:38 | Vladar | Araq, thanks |
| 21:17:57 | exhu | BTW, what was tyRecord? -) it's mentioned in system/hti.nim |
| 21:18:02 | Vladar | Araq, how about {.pure.}? |
| 21:18:32 | Araq | Vladar: now both final and pure are default for 'object' if it doesn't inherit anything |
| 21:18:55 | Vladar | Araq, ok, thanks again |
| 21:20:20 | Araq | exhu: the language had records but these turned into tuples |
| 21:25:07 | Vladar | Need to go, bye |
| 21:25:12 | Araq | argh |
| 21:25:15 | Araq | wait! |
| 21:25:20 | Vladar | ? |
| 21:25:31 | Araq | I'm fixing the bug that prevents nimgame from compiling |
| 21:25:50 | Araq | I'm quite sure it's "method"-related |
| 21:26:05 | Araq | your code is quite method-happy ... |
| 21:26:16 | Vladar | yeah ) |
| 21:27:41 | Araq | it's strange, I don't remember changing anything after 0.9.0 about the method implementation |
| 21:28:06 | reactormonk | Vladar, dynamic dispatch is slow, you know? :-P |
| 21:29:08 | Vladar | Araq, I remember this bug appeared around october, don't know exactly when |
| 21:29:18 | Araq | lol that hardly helps |
| 21:29:39 | reactormonk | Vladar, go bisect |
| 21:30:10 | Vladar | Araq, I'll try to get some logs from dropbox |
| 21:32:46 | Vladar | reactormonk, when you dealing with 2d-graphics output, dynamic dispatch isn't your biggest problem =] |
| 21:34:12 | reactormonk | Vladar, thought so |
| 21:51:57 | Araq | ok I think I got it |
| 21:56:31 | Araq | ok :D |
| 21:57:30 | * | gradha joined #nimrod |
| 21:57:54 | exhu | seems like people went to bed |
| 21:58:24 | Araq | Vladar: please try it |
| 21:58:53 | Araq | yay gradha |
| 21:59:02 | gradha | yay me |
| 21:59:14 | Araq | 25 users ... new record I think ;-) |
| 21:59:35 | gradha | does that count bots and the like? |
| 21:59:46 | Araq | yes ;-) |
| 21:59:58 | Araq | but we only have 2 bots here |
| 22:00:23 | exhu | btw why two bots? |
| 22:00:25 | zahary | Araq, is there a GC proc that I can modify a little bit to print some information about all objects on the heap? I'm a bit stuck as I've supposedly cleaned all global caches now, but the GC doesn't want to collect anything |
| 22:01:20 | dom96 | exhu: One is a brand new beta version. |
| 22:01:39 | dom96 | Running to make sure it works properly. |
| 22:02:03 | dom96 | Also, yay new record. |
| 22:02:06 | dom96 | NimBot should track this. |
| 22:02:33 | Araq | zahary: hrm there are lots of options, none without quite some tinkering |
| 22:05:08 | Vladar | Moment of truth... YEAH! |
| 22:05:33 | Vladar | Araq, thanks a lot |
| 22:05:50 | Araq | you're welcome but try to run your game please |
| 22:06:10 | gradha | what is the equivalent of "weak pointers" in nimrod? A reference to an object which can be garbage collected when the system is on low memory but usually persists for caching |
| 22:06:10 | Araq | I already know it compiles again :P |
| 22:06:55 | Araq | gradha: see tests/gc/weakrefs.nim |
| 22:07:10 | exhu | gradha, weak references were discussed on the forum, Araq presented some solution |
| 22:07:39 | Vladar | Araq, everything is compiling and working |
| 22:07:51 | exhu | btw, forum lacks search feature |
| 22:07:56 | gradha | thanks for the pointers |
| 22:08:01 | gradha | google is fast to show http://forum.nimrod-code.org/t/45 |
| 22:09:16 | Araq | IMHO it's a beautiful solution showing quite some elegance |
| 22:09:43 | gradha | oh man, jumping from end user code to library code with idetools makes me chuckle, such a joy to use |
| 22:11:56 | Araq | zahary: you could try to set 'x.owner = someDummyModule' and invoke the GC explicitly |
| 22:12:06 | exhu | that should be mentioned in the FAQ or manual/tutorial whatever |
| 22:12:33 | exhu | i tell about weak refs |
| 22:13:18 | zahary | what is the purpose of someDummyModule? I'm clearing all global roots to compiled modules and calling the GC with GC_fullcollect |
| 22:13:55 | zahary | I'm googling for heap snapshot analyzers - there seems to be some java based tools that work with a common format called "hprof" |
| 22:14:07 | Araq | well I think the code often relies on owner != nil |
| 22:14:31 | zahary | that would be powerful solution, but I could do with backtracing of references: "what roots point here?" |
| 22:14:38 | Araq | exhu: yeah yeah the docs suck, we know |
| 22:15:51 | exhu | do you accept pull requests to manual or where to put such info? |
| 22:16:11 | gradha | exhu: there is still hope weakref might transform from test case to library module |
| 22:16:28 | reactormonk | exhu, yep, should do |
| 22:16:29 | exhu | like "see weak references in tests/gc/weakrefs.nim TODO explain in details later" |
| 22:17:55 | Araq | I'm still not sure whether these things should be in the manual or the tutorial ... |
| 22:18:15 | Araq | in fact the manual is supposed to become a proper spec |
| 22:18:39 | Araq | but the tuts are too terse so people should read the manual instead ... |
| 22:18:51 | Vladar | ok, that's all for today, bye |
| 22:18:56 | Araq | bye, Vladar |
| 22:19:04 | * | Vladar quit (Quit: Leaving) |
| 22:19:20 | exhu | current documentation is of high quality, I mean wording, explanation etc. although some things are described in tutorials, other in compiler manual (like {.compile.} pragma) but I think it's ok for an open source project to have stubs like TODOs, copy-pasta, links to forums etc. |
| 22:20:53 | Araq | well we also kind of use the wiki on github |
| 22:22:37 | exhu | https://github.com/Araq/Nimrod/wiki/Unofficial-FAQ -- i can mention weak references here, is it appropriate place to? |
| 22:23:48 | Araq | meh I don't think many people read this page |
| 22:23:54 | dom96 | Perhaps we should create a github repo where we create a more lengthy tutorial documenting each feature of Nimrod in separate sections? |
| 22:24:40 | Araq | I'm not a fan of too many repositories but ok |
| 22:25:08 | Araq | the current tutorials are good as a starting point; lets add more stuff to them |
| 22:25:21 | gradha | I'm not understanding the weakref test, it creates 10_000 references, which are just objects holding an int, and they get nil in a few lines? why don't they persist? |
| 22:26:27 | Araq | well the GC is aggressive |
| 22:26:48 | dom96 | Araq: I think starting from a clean slate would allow us to be more detailed. I mean sure, we could use things from the current tutorial. |
| 22:27:28 | gradha | being that aggressive defeats the point of using those as a cache then |
| 22:27:54 | dom96 | A breakdown of what each section should contain would be nice as it would allow us to see what actually needs to be done. |
| 22:28:34 | Araq | well a whole new tutorial is fine with me too |
| 22:28:37 | exhu | well, cache differs, i was interested in weak refs just to keep a list of used objects, e.g. textures. If it is used it is stored in the cache, if it is not used it MAY be still stored... |
| 22:29:29 | dom96 | I will see what I can do. But I would love the support of the community as I don't have enough time to write all of it, it would be nice to see everyone writing some parts of it ;) |
| 22:29:33 | Araq | gradha: actually I prefer simple fixed size arrays for caching |
| 22:29:55 | Araq | dom96: see? that's why it's much easier to add to something that already exist ... :P |
| 22:30:55 | dom96 | Araq: It's even easier to do nothing. Do you want to be lazy and do nothing, or do you want quality docs? :P |
| 22:31:00 | exhu | yeah it's pain to find spare time and vigour to write docs -) |
| 22:32:05 | Araq | alright here we go: check our awesome docs; parts are in the manual, other parts in compiler's documentation, still other parts in the tutorial |
| 22:32:24 | Araq | and we improved the situation with another source of information :P |
| 22:33:35 | Araq | but as I said, go ahead |
| 22:34:06 | dom96 | I'll think about. You're not being very encouraging :P |
| 22:35:09 | dom96 | *about it |
| 22:36:01 | Araq | gradha: the weakrefs example is more about some "listener/observer"; "lets see if this object is still around, if so, tell it about some event" |
| 22:36:50 | zahary | btw, it's easy to write a weakref solution that will work in O(1) access time |
| 22:36:55 | Araq | for caching you could extend the lifetime artificially though |
| 22:37:14 | gradha | yes, recently in java had to use weakrefs and they had two types: the one which go dead ASAP and the ones that want to stay forever |
| 22:37:24 | Araq | hey, my solution is O(1) :P |
| 22:37:56 | zahary | you use IntSet? log(n) invalidation and access |
| 22:38:08 | gradha | for the "stay forever" kind i was going to ask if there is support for C requiring nimrod to "free memory" |
| 22:38:25 | zahary | ah, this is hash table |
| 22:38:36 | Araq | yes :P |
| 22:38:48 | zahary | ok, but I mean even better 0(1), just a memory lookup at fixed location |
| 22:38:53 | Araq | with packed bit representation |
| 22:39:51 | Araq | (yeah I know, we talked about it) |
| 22:40:02 | zahary | so lets discuss this GC problem |
| 22:40:57 | zahary | can we add a proc that will execute the "mark" algorithm to tell me about all paths to a given object? |
| 22:42:25 | Araq | do you have a single object in mind? |
| 22:42:37 | Araq | I mean can you do: |
| 22:42:45 | Araq | GC_track(thisObject) |
| 22:43:04 | Araq | after creation of 'thisObject'? |
| 22:43:41 | Araq | if so, I'd patch the write barrier to keep a list of parents |
| 22:44:32 | zahary | I can keep one ref to some particular module and execute GC_track to look for another paths to that object |
| 22:44:56 | Araq | yes that's what I have in mind |
| 22:49:39 | Araq | you could also hook into stack scanning and whenever a root is detected there make it output the graph belonging to it |
| 22:50:19 | Araq | the problem with these approaches is however that they are too slow very quickly and you get overwhelmed with noise |
| 22:51:14 | zahary | I imagine something that I can call on demand |
| 22:51:45 | Araq | well 'system.repr' can write general Nimrod graphs |
| 22:52:06 | Araq | but here is a better idea: |
| 22:52:22 | Araq | bite the bullet and enhance RTTI with class names |
| 22:52:39 | fowl | if i do {.link: "some.so".} it will look in ./ ? |
| 22:52:40 | Araq | then you can easily filter against object type |
| 22:52:47 | fowl | current dir* |
| 22:53:02 | Araq | fowl: dunno, try it |
| 22:53:37 | Araq | but hrm, class names are not good enough |
| 22:53:50 | Araq | perhaps we need an object cookie |
| 22:53:55 | exhu | type names, TTime is represented as akInt |
| 22:53:56 | zahary | I see some provisions for "when leakDetected" in the GC? how far does this go? |
| 22:54:22 | fowl | hm i guess it does |
| 22:57:13 | Araq | zahary: it's outdated but could be re-activated |
| 22:57:17 | gradha | looks like I can do var temp : string |
| 22:57:20 | gradha | then temp = nil |
| 22:57:32 | gradha | the compiler doesn't say anything, then at runtime there is a SIGSEV |
| 22:57:47 | * | exhu quit (Quit: Ex-Chat) |
| 22:57:53 | Araq | gradha: known bug :P |
| 22:58:07 | fowl | how is that a bug/ |
| 22:58:29 | Araq | well the language is a bit shizo with 'nil' strings ... |
| 22:58:45 | Araq | they are valid only as initialization state |
| 22:59:11 | Araq | you can't explicitly set them to nil, unless you can ... |
| 22:59:59 | Araq | zahary: the idea is that 'new' tracks filename and line information for every allocated object |
| 23:00:15 | Araq | but that doesn't help us now |
| 23:00:24 | zahary | yeah, I read the source |
| 23:00:45 | Araq | it was for GC leaks, not for logical leaks |
| 23:00:57 | zahary | global roots doesn't seem to be tracked on regular scans? they are only handled with unAssignRef? |
| 23:02:19 | Araq | this is correct |
| 23:03:17 | Araq | and indeed is a problem if we ever implement a tracing collector |
| 23:03:26 | * | Trix[a]r_za quit (Ping timeout: 256 seconds) |
| 23:04:07 | zahary | we'll just modify the codegen, but I was hoping to reuse the "list of globals" for some heap-dumping |
| 23:04:16 | zahary | anyway, moving on |
| 23:04:26 | Araq | btw did you try with boehm's GC? maybe it's not a logical leak but a real GC leak? |
| 23:04:47 | * | Trix[a]r_za joined #nimrod |
| 23:05:53 | Araq | and even if it's a logical leak, boehm has some support for finding leaks |
| 23:08:10 | zahary | that would be koch boot —gc:boehm, right? |
| 23:08:36 | Araq | right |
| 23:10:35 | * | gradha quit (Quit: gradha) |
| 23:18:29 | * | ekselkiu quit (Ping timeout: 260 seconds) |
| 23:41:05 | zahary | did you know that the refcount is incremented/decrement by 8? |
| 23:41:05 | zahary | (*c).Refcount -= 8; |
| 23:41:19 | zahary | peculiar, it's int in the code |
| 23:41:44 | Araq | of course I do |
| 23:41:59 | Araq | it's my way of keeping the last 3 bits 0 for some flags |
| 23:42:09 | Araq | well not touching the last 3 bits |
| 23:42:14 | zahary | aha, I see. so these ++ are special operator |
| 23:44:36 | * | dedis15 joined #nimrod |
| 23:44:56 | Araq | welcome dedis15 |
| 23:45:09 | Araq | (what's up today in here?) |
| 23:47:48 | dom96 | We've obviously been slashdotted. |
| 23:51:29 | * | q66 quit (Quit: Quit) |