| 00:06:47 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 00:59:37 | * | Trixar_za is now known as Trix[a]r_za |
| 01:11:18 | * | Boscop quit (Disconnected by services) |
| 01:11:21 | * | Boscop joined #nimrod |
| 01:23:36 | * | DAddYE quit (Remote host closed the connection) |
| 02:03:22 | * | fowl is now known as zz_fowl |
| 02:28:21 | * | zz_fowl is now known as fowl |
| 03:50:46 | * | silven quit (*.net *.split) |
| 03:50:48 | * | Raynes quit (*.net *.split) |
| 03:52:42 | * | silven joined #nimrod |
| 03:52:42 | * | Raynes joined #nimrod |
| 03:53:59 | * | silven quit (*.net *.split) |
| 03:53:59 | * | Raynes quit (*.net *.split) |
| 03:55:39 | * | silven joined #nimrod |
| 03:55:39 | * | Raynes joined #nimrod |
| 04:22:38 | * | OrionPK quit (Read error: Connection reset by peer) |
| 06:06:50 | * | q66 joined #nimrod |
| 06:09:56 | * | Amrykid quit (Read error: Operation timed out) |
| 06:13:06 | * | Amrykid joined #nimrod |
| 06:38:45 | * | comex quit (Quit: Coyote finally caught me) |
| 07:14:50 | * | comex joined #nimrod |
| 07:43:26 | * | comex quit (Quit: Coyote finally caught me) |
| 08:30:53 | * | comex joined #nimrod |
| 09:11:36 | * | Araq_ joined #nimrod |
| 10:08:52 | * | EXetoC joined #nimrod |
| 10:21:25 | Araq_ | ping zahary_ |
| 10:21:33 | zahary_ | hi |
| 10:22:55 | Araq_ | I'm planning a pure reference counting GC for the shared memory heap |
| 10:23:13 | Araq_ | so that no stack walkings whatsoever are necessary |
| 10:23:25 | Araq_ | this means it never needs to stop any thread |
| 10:23:31 | zahary_ | throwing out deferred counting? |
| 10:23:40 | Araq_ | yeah |
| 10:24:01 | zahary_ | if the papers are to be trusted this should work very well |
| 10:24:07 | Araq_ | so I've been thinking how to optimize/detect not owning pointers |
| 10:24:26 | Araq_ | but it's quite hard |
| 10:24:30 | zahary_ | this shouldn;t |
| 10:24:33 | Araq_ | for now the rule is: |
| 10:25:08 | Araq_ | if the variable v is local and the proc doesn't perform write access to a location that may alias what v points to |
| 10:25:25 | Araq_ | for instance: |
| 10:25:36 | Araq_ | var it = head; while it != nil: |
| 10:25:56 | Araq_ | it.prev = it.next # deletes node 'it' |
| 10:26:00 | Araq_ | use(it) |
| 10:26:04 | Araq_ | it = it.next |
| 10:26:22 | Araq_ | 'it' then keeps the node alive |
| 10:26:33 | zahary_ | why are you trying to invent the rules. there was a paper analyzing the problem |
| 10:26:36 | Araq_ | so you need to perform RC ops for it |
| 10:27:08 | Araq_ | yeah but I lost the paper :P |
| 10:27:19 | Araq_ | and it's always more fun to think for yourself |
| 10:27:49 | zahary_ | it seemed complicated and we'll probably get it wrong as fun as it is :) |
| 10:28:55 | Araq_ | my rule may be overly conservative |
| 10:29:01 | Araq_ | but I'm pretty sure it's correct |
| 10:31:03 | zahary_ | so, where are the increments/decrements in your example? |
| 10:32:52 | Araq_ | for the it.prev = it.next the usual ops |
| 10:33:33 | Araq_ | for 'it' we do the same but in addition need an try: ... finally: if it != nil: decRef(it) |
| 10:34:02 | Araq_ | which is expensive |
| 10:36:52 | zahary_ | maybe this was the paper? http://www.hpl.hp.com/personal/Pramod_Joisha/Publications/ismm06.pdf |
| 10:37:30 | zahary_ | you should still remember that the refcount updates require some form of locking (atomic ops are not sufficient) |
| 10:39:03 | Araq_ | it there are no write operations to the heap that may influence 'it' (unlike the example) you can avoid the RC ops for 'it' |
| 10:39:30 | Araq_ | (unless 'it' points to newly allocated memory ...) |
| 10:39:34 | zahary_ | the most touted algorithm in the literature (the one using the alternative write barriers) doesn't require locking and has a cheaper write barrier in the common case |
| 10:40:57 | Araq_ | however for "shared ref" the cost should be acceptable |
| 10:42:35 | zahary_ | I'm not that convinced that shared ref should be rarely used. maybe serial types (unique smart pointers) will prove to be most widely used type |
| 10:51:57 | Araq_ | yeah well ... thanks to aliasing everything is hard |
| 10:52:33 | Araq_ | and I haven't found any good papers about linear types for now |
| 10:53:16 | * | Araq_ quit (Read error: Connection timed out) |
| 10:53:33 | zahary_ | linear types are a simple concept in my opinion. the implementation in otherwise immutable languages is what creates the need for complicated papers |
| 10:53:57 | zahary_ | a linear type is just a value that can have a single reference in the program at any point |
| 10:54:07 | zahary_ | C++'s unique_ptr would be an example |
| 10:54:53 | zahary_ | they can be implemented easily as user types once value semantics are in place |
| 10:54:55 | * | Araq_ joined #nimrod |
| 10:55:14 | zahary_ | linear types are a simple concept in my opinion. the implementation in otherwise immutable languages is what creates the need for complicated papers |
| 10:55:19 | zahary_ | linear type is just a value that can have a single reference in the program at any point |
| 10:55:23 | zahary_ | C++'s unique_ptr would be an example |
| 10:55:26 | zahary_ | they can be implemented easily as user types once value semantics are in place |
| 10:57:29 | Araq_ | I dunno; "a nonlinear data structure must not contain any linear components" is a common restriction |
| 10:58:09 | zahary_ | this follows naturally in C++ due to the lack of copy constructor of unique_ptr |
| 10:58:36 | zahary_ | any type that has a unique_ptr member will get only a default move constructor implicitly |
| 10:59:49 | Araq_ | how does that help? C++ doesn't prevent arbitrary nesting of types |
| 11:00:22 | Araq_ | alright I see |
| 11:00:25 | zahary_ | but it's transitive with regard to nesting. if you don't get a default copy ... |
| 11:14:28 | Araq_ | "the most touted algorithm in the literature ..." can you find that paper again please? |
| 11:15:56 | * | Araq_ quit (Read error: Connection timed out) |
| 11:16:55 | * | Araq_ joined #nimrod |
| 11:16:57 | zahary_ | there is a stand-alone paper, but what was easier to find is the complete master thesis of one of the authors |
| 11:17:01 | zahary_ | http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2006/PHD/PHD-2006-10.pdf |
| 11:17:29 | zahary_ | 3. An On-the-Fly Mark-and-Sweep Garbage Collector Based on Sliding Views |
| 11:17:38 | zahary_ | the write barrier and the general algorithm is explained here |
| 11:19:37 | zahary_ | note that the same barrier is used in another GC, which claims to be faster, but requires precise stack marking |
| 11:19:37 | zahary_ | http://grothoff.org/christian/teaching/2007/4705/urc-oopsla-2003.pdf |
| 11:20:37 | zahary_ | it uses bump-pointer heap for new objects (nursery) that are moved to a regular heap if they survice |
| 11:20:43 | zahary_ | survive |
| 11:21:37 | zahary_ | but it's also true that nimrod challenges the generational hypothesis with our stack allocated objects. maybe these nurseries won't help us much |
| 11:35:18 | * | Amrykid quit (Changing host) |
| 11:35:18 | * | Amrykid joined #nimrod |
| 11:40:17 | Araq_ | and what's worse ... it complicates the write barrier even further |
| 11:41:15 | zahary_ | complicates as in "more core"? |
| 11:42:45 | * | Trix[a]r_za is now known as Trixar_za |
| 11:44:09 | Araq_ | yeah |
| 11:44:25 | Araq_ | and the generational write barrier requires the object owner |
| 11:44:38 | zahary_ | I've implemented that part in the codegen |
| 11:44:43 | Araq_ | which the codegen doesn't emit and which may not be available for 'var ref' |
| 11:45:25 | zahary_ | what is special about var ref? |
| 11:47:34 | Araq_ | the traditional write barrier injects obj.field = x |
| 11:47:54 | Araq_ | with 'var ref' the obj.field access can be split up in arbitrary ways |
| 11:48:14 | zahary_ | ah, sure. I've thought about this too |
| 11:48:43 | zahary_ | it's not implemented yet, but it's possible to pass the owner as well in call-sites. |
| 11:49:08 | zahary_ | the var ptr param will just get "fatter" |
| 11:51:07 | * | Araq_ quit (Read error: Connection timed out) |
| 11:51:51 | * | Araq_ joined #nimrod |
| 12:01:47 | Araq_ | that's one way of doing it, the other being to call interiorPointer(...) to get the owner's address |
| 12:02:22 | zahary_ | yep, forgot about this one |
| 12:02:27 | Araq_ | it's expensive but currently we already have an unsureAsgnRef |
| 12:07:52 | Araq_ | well I can't see me implementing "An On-the-Fly Mark-and-Sweep Garbage Collector Based on Sliding Views"; I'll go for the pure RC GC |
| 12:08:23 | Araq_ | and yeah it'll use atomicInc/Dec + locks in the GC |
| 12:11:43 | zahary_ | I had an idea to make the --gc:... switch just point to a file containing a bunch of required constants (besides the implementation) that tell the codegen to use certain kind of write barriers or certain kinds of stack marking |
| 12:12:04 | zahary_ | do you welcome such change? then we'll be able to have a plethora of GCs |
| 12:15:42 | zahary_ | then I'll go to the GC mailing list to explain how much easier to use Nimrod is compared to Jikes VM (the current golden standard for GC experimentation) |
| 12:19:18 | Araq_ | the idea is not bad, but perhaps we should make that --gcImpl switch and keep --gc as it is |
| 12:20:13 | Araq_ | or we make the codegen check for the existance of some symbols via the compilerproc mechanism |
| 12:21:20 | Araq_ | and compilerproc needs to be renamed to cgsym or something anyway |
| 12:21:30 | zahary_ | how does that work? these implementation details were the reason I didn't go ahead with it |
| 12:27:53 | Araq_ | type RequiresRCWriteBarrier {.compilerproc.} = object # in gc.nim |
| 12:28:11 | Araq_ | in the codegen: if getCompilerProc("RequiresRCWriteBarrier") != nil: ... |
| 12:28:47 | Araq_ | it's uglier than necessary because {.define.} has been deprecated |
| 12:29:05 | zahary_ | I thought it woudn't be too hard to get a value of a named constant in cgen |
| 12:29:37 | zahary_ | const WriteBarrierType = wbOwner |
| 12:29:58 | zahary_ | the value |
| 12:31:43 | Araq_ | I don't think there are compilerproc consts |
| 12:32:04 | Araq_ | and without the compilerproc the symbol is not guaranteed to be kept |
| 12:32:09 | zahary_ | but the value is in the symbol table (the ast field of the const symbol) |
| 12:32:55 | zahary_ | heck, even a magic would be simple to implement. WriteBarrierType wbOwner |
| 12:39:34 | Araq_ | the symbol table is not persistent ... well it used to not be |
| 12:45:18 | * | Araq_ quit (Read error: Connection timed out) |
| 12:46:56 | * | Araq_ joined #nimrod |
| 13:00:41 | EXetoC | is it possible to get the root AST node? I couldn't find anything relevant |
| 13:04:56 | Araq_ | EXetoC: within a macro you can use callsite() |
| 13:05:20 | Araq_ | you can't get up further by design |
| 13:20:03 | EXetoC | ok. that's barely an inconvenience |
| 13:43:01 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 13:47:27 | EXetoC | some changelog mentioned getting closer to unifying of expression and statements. is that statements as expressions or something else? |
| 13:48:55 | EXetoC | which is a very convenient feature |
| 14:07:41 | * | Trixar_za is now known as Trix[a]r_za |
| 14:18:30 | EXetoC | this often throws because it cannot always find "name": (it.kind == nnkProcDef or it.kind == nnkMethodDef) and it.name.baseName.ident == !"inv") |
| 14:19:00 | EXetoC | this looks similar to classimpl's approach, so what's going on? is short circuiting working like in other languages? |
| 14:19:40 | EXetoC | I'll try to divide it into several if statements and see if it works then |
| 14:21:15 | EXetoC | actually, it might be failing on the next line |
| 14:32:55 | EXetoC | uh yeah, callsite() doesn't really give me anything new. is it possible to check if a certain node will compile? |
| 14:35:49 | EXetoC | otherwise I'll just have to blindly insert new nodes and hope for the best |
| 14:36:01 | zahary_ | there is system.compiles, but it's currently not possible to directly check AST values against it. we should fix that, but currently it's only possible to return a block from the macro that uses system.compiles in a when statement |
| 14:36:07 | zahary_ | https://github.com/Araq/Nimrod/blob/master/lib/pure/unittest.nim#L117 |
| 14:36:49 | zahary_ | this is an example from the unittest module, you should see how these templates are used with getAst |
| 14:41:35 | EXetoC | yeah, so it's just a matter of converting to a string first |
| 14:42:24 | zahary_ | er, no. it's just that the purpose of the check in the unittest module is to determine whether the type is convertible to string |
| 14:42:48 | zahary_ | the goal is to print intermediate values (if that's possible) |
| 14:43:26 | zahary_ | you could have an arbitrary expression as an argument to compiles(...) |
| 14:45:33 | EXetoC | uh yeah |
| 16:21:08 | * | Endy joined #nimrod |
| 16:31:21 | fowl | EXetoC, what are you having trouble with |
| 16:44:24 | reactormonk | proc makeDocList*(numFiles: cint): ptr ptr ptr wordEntry = |
| 16:44:26 | reactormonk | O.o |
| 16:44:26 | * | DAddYE joined #nimrod |
| 16:45:27 | fowl | lol |
| 16:45:49 | fowl | im going through this, see what it takes to do stuff in nimrod http://developer.ubuntu.com/get-started/ |
| 16:46:48 | reactormonk | QT-based? |
| 16:47:30 | fowl | yea |
| 16:47:34 | fowl | qt5 |
| 16:48:30 | fowl | is that going to be a problem |
| 16:51:21 | fowl | looks like little code has to be written |
| 17:05:56 | EXetoC | fowl: checking if a call compiles |
| 17:10:16 | EXetoC | in AST form |
| 17:15:07 | EXetoC | zahary_: so an AST can't be converted to an expr then? |
| 17:20:48 | fowl | i got it working.. |
| 17:21:14 | fowl | https://gist.github.com/fowlmouth/baf4772bac7a38bf8161 |
| 17:21:32 | fowl | o nm |
| 17:21:35 | fowl | getAsp >_> |
| 17:22:02 | fowl | with getast i got a segfault :D |
| 17:40:13 | Araq | nice ... -.- |
| 17:55:55 | * | fowl- joined #nimrod |
| 18:00:08 | * | DAddYE quit (*.net *.split) |
| 18:00:09 | * | fowl quit (*.net *.split) |
| 18:02:36 | * | DAddYE joined #nimrod |
| 18:02:38 | fowl- | Araq, should i file an issue |
| 18:07:35 | EXetoC | oh ok |
| 18:08:28 | Araq | fowl-: yes please |
| 18:09:38 | fowl- | ok |
| 18:10:35 | fowl- | so that should work |
| 18:10:40 | fowl- | compiles(getAst(exp)) ? |
| 18:11:02 | Araq | I dunno but it mustn't crash the compiler |
| 18:11:21 | fowl- | aye |
| 18:12:08 | EXetoC | Araq: cmon, don't take away all the challenges |
| 18:13:21 | * | Trix[a]r_za is now known as Trixar_za |
| 18:25:07 | * | Endy quit (Ping timeout: 268 seconds) |
| 18:32:44 | * | fowl- is now known as fowl |
| 18:32:48 | * | fowl quit (Changing host) |
| 18:32:48 | * | fowl joined #nimrod |
| 18:51:22 | * | sbenitez joined #nimrod |
| 18:51:56 | * | sbenitez is now known as whoknows |
| 18:52:14 | * | whoknows is now known as nooneknows |
| 18:52:33 | nooneknows | Hi all. I'm having a problem compiling with the standalone os target. |
| 18:52:53 | nooneknows | Specifically: Error: system module needs 'addChar'. |
| 18:55:37 | nooneknows | I see system.nim:934 should not include "system/cgprocs" when hostOs == standalone. Is this a bug, then? |
| 18:56:10 | fowl | nooneknows, someone will be along who knows more about it |
| 19:00:33 | nooneknows | Great, thanks. :) |
| 19:01:58 | reactormonk | nooneknows, where do you want to run it on? |
| 19:04:14 | Araq | hi nooneknows , welcome |
| 19:04:29 | Araq | yeah I know --os:standalone doesn't work anymore |
| 19:05:01 | reactormonk | Araq, can't wrap my head around that progmem stuff :-( |
| 19:05:29 | Araq | you need to wrap some 'add' definition in a 'when hostOs != "standalone"' section |
| 19:06:23 | Araq | I think it's the one in line 1746 in system.nim |
| 19:07:22 | Araq | reactormonk: just ignore the progmem crap then? and as I said, it's not important that 'raise' works properly when you've got 16K of RAM ... |
| 19:08:07 | reactormonk | Araq, just kick the exception? I don't like that either |
| 19:08:27 | reactormonk | and I need to figure out how to store structs in the progmem anyway |
| 19:13:07 | Araq | looks like we need another pragma |
| 19:13:27 | Araq | something like "annotation" that allows for more flexibility how things are declared |
| 19:13:55 | reactormonk | sadly, yep |
| 19:14:05 | Araq | var x {.annotation: "$# progmem $#".}: int ? |
| 19:14:11 | reactormonk | actually having my new pointer type would be sweet |
| 19:14:58 | reactormonk | why not. But you can't capture certain stuff with that, such as that you cannot dereference with * there |
| 19:15:04 | reactormonk | you need pgm_read_word |
| 19:15:17 | Araq | gah that sounds nasty |
| 19:15:58 | reactormonk | yup |
| 19:16:20 | reactormonk | because PROGMEM has its own address space, you need *_P functions for that, or pgm_read_* stuff |
| 19:19:00 | reactormonk | I could work with different types here, but I think that annotation pragma would help |
| 19:20:13 | reactormonk | The best way would be to have a {.progmem.} that takes care of the annotation and changes the type of the variable so I can add converters that read the stuff from progmem if needed and if not, pass the correct types on to C functions |
| 19:20:36 | Araq | well if you need accessors anyway what's wrong with a "distinct ptr"? |
| 19:20:53 | reactormonk | prog_pointer = distinct pointer |
| 19:21:01 | Araq | nah |
| 19:23:57 | Araq | type TX {.extern: "int* progmem".} = distinct ptr int16 |
| 19:24:42 | Araq | proc `[]`(x: TX): int16 = pgm_read_int(x) |
| 19:25:05 | reactormonk | ah |
| 19:25:26 | reactormonk | does the compiler call [] automatically? |
| 19:25:34 | Araq | no |
| 19:25:55 | reactormonk | Let's give converters some love |
| 19:50:48 | EXetoC | are there functions that specifically give everything before FormalParams? 'name' is one of them, and stmt[0] is just ProcDef so that's easy to remember, but there's Empty x2 just before FormalParams |
| 19:52:44 | nooneknows | Araq: Thanks. That fixed the addChar. Now I see "system module need 'copyString'. |
| 19:52:57 | fowl | no EXetoC |
| 19:53:21 | fowl | formalparams is like this: [resultType, identDef(arg1name, arg1type, arg1default), ...] |
| 19:53:50 | fowl | paste and ill check it out |
| 19:54:22 | nooneknows | The only reference I see to sysstr is on system.nim:2129 |
| 19:55:27 | reactormonk | nooneknows, which processor do you want it to run on? |
| 19:56:10 | fowl | nooneknows, are you using nimgrep to search |
| 19:56:15 | nooneknows | i586 |
| 19:56:34 | fowl | nooneknows, standalone is for embedded devices |
| 19:56:46 | nooneknows | On bare metal... |
| 19:57:38 | reactormonk | oh. |
| 19:57:52 | nooneknows | I'm just using grep to search. |
| 19:58:55 | fowl | its probably not used with different case/styles but its best to search for an identifier with nimgrep --ignorestyle |
| 19:59:18 | fowl | that way you can find s_y_S_s_t_R if its typed like that |
| 20:02:31 | nooneknows | No further matches with nimgrep. |
| 20:08:25 | nooneknows | Ah, I see system.nim:1079. I believe that's the culprint. |
| 20:08:30 | nooneknows | culprit* |
| 20:08:49 | EXetoC | fowl: I was just looking for a convenience function. the layout is static so adding it manually should be easy |
| 20:09:33 | fowl | EXetoC, oh you were asking about the layout of a proc node? |
| 20:09:45 | fowl | EXetoC, do this in a new file: import macros |
| 20:09:48 | fowl | dumptree: |
| 20:10:08 | fowl | proc foo [A] (some: A): B {.foo.} = |
| 20:10:13 | fowl | nil |
| 20:10:50 | fowl | that should have most of the fields filled out |
| 20:11:10 | fowl | there are helper funcs like name() for that reason though |
| 20:12:07 | nooneknows | Nope. |
| 20:13:59 | nooneknows | reactormonk: I see you were having similar issues a while ago. Did you ever get it sorted out? |
| 20:15:46 | reactormonk | nooneknows, still on it, should run on arduino afterwards |
| 20:16:14 | nooneknows | Is it compiling with --os:standalone? |
| 20:37:00 | reactormonk | nope |
| 20:37:43 | reactormonk | Araq, can I somehow query the size of a type? |
| 20:38:14 | fowl | sizeof() |
| 20:40:43 | reactormonk | now the interesting part is that I can only read in word/dword sizes... which is different form platform to platform :-/ |
| 20:41:21 | reactormonk | Araq, any way I can fuck with the assignment copy? :-) |
| 20:43:23 | reactormonk | screw it, don't need that |
| 20:44:05 | fowl | nooneknows, are you trying to write a kernel or somethign |
| 20:44:12 | nooneknows | Yes. |
| 20:44:21 | fowl | cool |
| 20:44:36 | EXetoC | fowl: nah I was using treeRepr for that |
| 20:44:41 | Araq | dom96 used to have a kernel written in nimrod |
| 20:44:53 | fowl | yea but he never published it |
| 20:44:57 | fowl | =( |
| 20:45:19 | fowl | i wrote an oracle in nimrod once |
| 20:45:52 | fowl | it was capable of solving 1000 what-is-the-meaning-of-life's per second |
| 20:45:52 | fowl | but i didnt upload it anywhere |
| 20:45:53 | dom96 | I wouldn't call it a kernel, but I still have it somewhere. |
| 20:46:01 | dom96 | I'm guessing it won't work anymore. |
| 20:46:02 | reactormonk | Araq, is it reasonable to have a memcpy that copies stuff from progmem to RAM? |
| 20:46:08 | reactormonk | ... without typecheck. |
| 20:46:17 | reactormonk | because I wouldn't know how to do that. |
| 20:46:52 | reactormonk | wait, maybe generics |
| 20:47:54 | reactormonk | any way to attach a generic to a distinct pointer? So I can have prog_ptr[char] afterwards? |
| 20:48:25 | fowl | type prog_ptr [X] = distinct ptr X ? |
| 20:48:56 | reactormonk | basically |
| 20:51:49 | reactormonk | seems to compile |
| 20:55:37 | Araq | reactormonk: I don't think memcpy can deal with it |
| 20:56:26 | Araq | and I'm beginning to wonder if you can be of more help to us :P |
| 20:56:34 | Araq | why not play with the JS backend again? |
| 20:57:31 | reactormonk | Araq, because that's my current project ;-) |
| 20:57:52 | Araq | nooneknows: if you write a kernel, it might be easier to not do that via --os:standalone but instead make the GC/memory manager work with your kernel |
| 20:58:46 | Araq | basically you need to provide a simple osAllocPages() |
| 20:58:56 | Araq | you can use a static array and provide the memory from that |
| 20:59:27 | nooneknows | What is system.c? |
| 20:59:38 | reactormonk | nooneknows, the nimrod stdlib |
| 20:59:49 | fowl | the result of system.nim |
| 21:01:07 | nooneknows | Araq, so you're saying I should include the runtime with the kernel? Doesn't the runtime make use of a lot of system funtions? |
| 21:03:05 | nooneknows | Doing --gc:none -d:useMalloc gives me: Error: undeclared indentifer: 'TCellSet' |
| 21:04:13 | Araq | I know |
| 21:04:19 | Araq | don't use that |
| 21:04:27 | Araq | make it work with your kernel instead of disabling it |
| 21:05:33 | nooneknows | system.c uses errno, mman, stdio, and signal from libc. Writing this code would take a substantial amount of time. |
| 21:14:55 | Araq | well I know a guy who managed to massage system.nim and got it to work |
| 21:15:43 | nooneknows | Sure, but "massaging" it, or eliminating it, is what the --os:standalone flag should do, isn't it? |
| 21:16:09 | Araq | I'm not sure |
| 21:16:31 | Araq | --os:standalone may also mean "embedded" |
| 21:16:41 | fowl | my oracle is saying that hope in anything is illogical, and that the only sane course of action is to dance around naked |
| 21:17:35 | dom96 | from what I remember, I specified my own custom system.nim, if that helps. I'm on Windows currently so I can't check my code. |
| 21:21:28 | * | EXetoC quit (Ping timeout: 246 seconds) |
| 21:22:18 | dom96 | I'll dig up the code and try to get it running again tomorrow, that is if I don't end up playing Kerbal Space Program all day. |
| 21:23:30 | reactormonk | now I have a byte and a ptr. How do I write that byte to that specific ptr? |
| 21:25:02 | Araq | cast[ptr byte](p) = b |
| 21:28:33 | reactormonk | so basically http://sprunge.us/JcOL |
| 21:30:13 | reactormonk | now, how do I get the target if I want var foo = <something in progmem> |
| 21:30:55 | fowl | how would you do it in c |
| 21:34:36 | reactormonk | in nimrod, basically var foo: T; memcpy(bar, foo) |
| 21:35:18 | dom96 | so you want: var foo = bar? |
| 21:35:50 | nooneknows | What is setStackBottom supposed to do? |
| 21:36:59 | reactormonk | dom96, yep |
| 21:37:27 | reactormonk | dom96, actually var foo = bar[] if possible |
| 21:37:45 | reactormonk | but I'd settle with var foo = bar |
| 21:37:47 | nooneknows | ls |
| 21:37:49 | nooneknows | woops. |
| 21:38:08 | * | EXetoC joined #nimrod |
| 21:38:20 | dom96 | reactormonk: Maybe you could overload [], you can't currently overload `=`. |
| 21:38:44 | reactormonk | dom96, so I'll settle with the allocate, then copy |
| 21:39:08 | dom96 | or just creat a proc which does it, now that I think about it I don't think it's possible to overload [] that way. |
| 21:39:13 | dom96 | *create |
| 21:39:29 | dom96 | A proc with a name like "getMem" or something. |
| 21:45:19 | dom96 | Araq: oh cool, maybe gradha will beat you to creating a blog. :P |
| 21:51:05 | fowl | reactormonk, write a template for := |
| 21:51:48 | reactormonk | fowl, would be an idea |
| 21:55:05 | reactormonk | Araq, the pragma you mentioned, could I use that one for type prog_ptr[X] = distinct ptr X in such a way that var foo: prog_ptr[TFoo] = ... generates TFoo foo PROGMEM = ... ? |
| 21:55:38 | Araq | I'm not sure |
| 21:57:03 | EXetoC | what goes between Pragma and StmtList? I thought maybe it was the optional comment as indicated by the grammar, but adding one changes nothing |
| 21:57:45 | * | nooneknows is now known as sbenitez |
| 21:58:18 | * | sbenitez is now known as sergio965 |
| 21:58:20 | * | sergio965 is now known as Sergio965 |
| 21:59:57 | Araq | EXetoC: I don't understand your question |
| 22:00:39 | fowl | EXetoC, like i said stop worrying about the structure of the proc node and just use the helper functions, i wrote them so you dont have to remember node[6] is the statement list |
| 22:01:20 | EXetoC | Araq: in the proc AST. ...FormalParams, Pragma, Empty, StmtList... |
| 22:01:56 | EXetoC | fowl: there's nothing for index number 6. I'm just curious |
| 22:02:05 | EXetoC | I am using those that are there already |
| 22:03:07 | Araq | there are also empty positions for later additions |
| 22:03:55 | EXetoC | alright thanks |
| 22:08:40 | EXetoC | only return value interception left then. let's see if there are any caveats related to that |
| 22:10:52 | * | Trixar_za is now known as Trix[a]r_za |
| 22:15:53 | Sergio965 | Does Nimrod allocate 1000000001 bytes for strings? |
| 22:16:13 | Araq | what do you think? |
| 22:16:29 | Sergio965 | No, but the typedef is char[10000001]. |
| 22:16:31 | Sergio965 | Or whatever. |
| 22:17:38 | EXetoC | ofc it does. gotta avoid those re-allocations :> |
| 22:17:51 | Sergio965 | Eh? |
| 22:18:07 | EXetoC | not quite that I think. it's just a range isn't it |
| 22:18:16 | EXetoC | should be documented somewhere. let me check |
| 22:18:33 | Araq | dunno where that comes from but in general I prefer weird/wrong upper bounds so that bounds checking can stay turned on |
| 22:18:52 | Sergio965 | How does that affect bounds checking? |
| 22:19:16 | Sergio965 | Strings in Nimrod have lengths associated with them. |
| 22:19:55 | Araq | for instance: |
| 22:20:01 | Sergio965 | Strings are: struct { tseq struct { int lin; int reserved; }, char[10000001] } |
| 22:20:08 | Sergio965 | int len* |
| 22:20:39 | Araq | type a = ptr array [0..1000_000, char] |
| 22:20:58 | Araq | var v = cast[a](alloc(100)) |
| 22:21:11 | Araq | v[10] # compiles |
| 22:21:53 | Araq | simulates C's unchecked arrays and there is no need for {.push checks:off.} |
| 22:22:05 | Sergio965 | Doesn't it consume a lot of memory? |
| 22:22:12 | Araq | look at my code |
| 22:22:19 | Sergio965 | Well, not yours. |
| 22:22:31 | Araq | well the other code does the same |
| 22:22:49 | Sergio965 | Perhaps it's because I turned off bounds checking that I see this? |
| 22:23:03 | Araq | it's only a declaration |
| 22:23:09 | Araq | it lies |
| 22:23:17 | Sergio965 | But the string is allocated statically. |
| 22:25:06 | EXetoC | uh oh "lib/nimrod/core/macros.nim(329, 26) Error: internal error: expr(skMacro); unknown symbol" |
| 22:25:16 | EXetoC | will create a test case soon |
| 22:25:56 | Araq | looks like I need to fix bugs before implementing new features ... |
| 22:26:00 | Sergio965 | http://pastebin.com/83X38d6u |
| 22:26:14 | Sergio965 | Won't TMP62 be really large? |
| 22:26:34 | Sergio965 | Sorry, there's supposed to be a typedef char NIM_CHAR: at the top. |
| 22:27:23 | Araq | yeah but the compiler shouldn't generate that ... |
| 22:27:30 | Sergio965 | But it did! |
| 22:28:04 | Araq | which code makes it generate that? |
| 22:28:49 | EXetoC | don't worry, we'll survive a little longer even with such a tiny feature set :-) |
| 22:29:09 | Sergio965 | http://pastebin.com/4TS5iit8 |
| 22:29:26 | Sergio965 | (It does nothing.) |
| 22:31:07 | Sergio965 | I'm compiling with c --gc:none --noMain --stackTrace:off --lineTrace:off -c |
| 22:34:51 | Araq | the compiler only uses NimStringDesc* for me ... |
| 22:34:58 | Araq | which is a pointer |
| 22:36:07 | Araq | the literals come from STRING_LITERAL which uses an array of a proper size |
| 22:38:10 | Sergio965 | The code I showed you was what I got when I ran it through the preprocessor. |
| 22:39:55 | Sergio965 | Oh. |
| 22:40:20 | * | Sergio965 whistles |
| 22:40:24 | Sergio965 | Sorry. :) |
| 22:40:53 | Sergio965 | I converted some of the code by hand to be more readable and I misread the struct constructor. |
| 22:41:01 | Sergio965 | Er, not converted, but rewrote for clarity. |
| 22:42:21 | Sergio965 | :q |
| 22:42:23 | Sergio965 | Sigh. |
| 22:43:44 | * | OrionPK joined #nimrod |
| 23:02:29 | Sergio965 | How do I change the output directory to be something other than numcache? |
| 23:02:32 | Sergio965 | nimcache* |
| 23:02:42 | Araq | --nimcache:path |
| 23:05:24 | Sergio965 | Thanks. :) |
| 23:17:50 | Sergio965 | Is there a way to make it write to a parent directory? |
| 23:19:06 | Sergio965 | Nevermind. |
| 23:35:57 | * | DAddYE quit (Remote host closed the connection) |
| 23:36:51 | * | SirSkidmore left #nimrod ("WeeChat 0.4.0") |
| 23:42:13 | Sergio965 | Can I not do something like: var p: ptr = ptr(0x1000)? |
| 23:44:13 | OrionPK | dear god |
| 23:44:41 | Sergio965 | Indeed. |
| 23:47:04 | * | q66 quit (Remote host closed the connection) |
| 23:49:30 | Sergio965 | If I could, that'd be awesome. |