<< 22-08-2013 >>
00:12:37*noam joined #nimrod
01:01:01*BitPuffin quit (Remote host closed the connection)
01:32:42*zahary1 quit (Read error: Connection reset by peer)
01:32:54*zahary joined #nimrod
02:13:11*q66 quit (Quit: Leaving)
02:26:33*xilo joined #nimrod
04:20:30*Zor quit (Ping timeout: 268 seconds)
04:28:37*OrionPK quit (Read error: Connection reset by peer)
04:33:56*Associat0r quit (Quit: Associat0r)
05:15:04*XAMPP quit (Read error: Connection reset by peer)
05:18:20*reactormonk quit (Ping timeout: 260 seconds)
05:44:46*reactormonk joined #nimrod
06:14:38*Boscop quit (Disconnected by services)
07:14:55*Boscop joined #nimrod
07:19:54*Boscop quit (Disconnected by services)
07:20:35*Araq_ joined #nimrod
07:25:24*reactormonk quit (Ping timeout: 276 seconds)
07:26:34*reactormonk joined #nimrod
07:55:06*EXetoC joined #nimrod
08:20:12*Boscop joined #nimrod
09:09:15*q66 joined #nimrod
09:10:30*Boscop quit (Disconnected by services)
10:10:44*Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
10:10:44*Boscop joined #nimrod
10:15:36*Associat0r joined #nimrod
10:15:36*Associat0r quit (Changing host)
10:15:36*Associat0r joined #nimrod
10:41:33EXetoCåäö
11:11:16*[1]charles quit (Ping timeout: 256 seconds)
11:11:26*Boscop quit (Disconnected by services)
11:52:52dom96hey
12:00:35*BitPuffin joined #nimrod
12:11:41*Boscop joined #nimrod
12:15:58*Boscop quit (Disconnected by services)
12:24:11*Araq_ joined #nimrod
12:50:32*BitPuffin quit (Remote host closed the connection)
13:08:56*BitPuffin joined #nimrod
13:16:11*Boscop joined #nimrod
14:16:55*Boscop quit (Disconnected by services)
15:17:09*Boscop joined #nimrod
15:54:19BitPuffinhmm, why isn't gtk3 added to the stdlib?
16:15:46EXetoClack of manpower would be my guess
16:17:22BitPuffinyeah that's my guess too
16:17:29BitPuffinwas mostly wondering if there was some other
16:17:32BitPuffinreason
16:17:34*Boscop quit (Disconnected by services)
16:34:22EXetoCI tried to convert the pascal binding, but it failed on the first procedure declaration
16:34:49EXetoC"procedure add_child(builder: PGtkBuilder; child: PGObject; type_: Pgchar); cdecl; inline" Inspired by pascal indeed. there are quite a few similarities
16:37:27EXetoCAraq: Can I make it work somehow?
16:43:09EXetoCthis is preceded by "TGtkBuildable = object", and I get "Error: identifier expected, but found 'procedure'". https://svn.code.sf.net/p/lazarus-ccr/svn/bindings/gtk3/gtk3.pas
16:51:24*Sergio965 joined #nimrod
17:03:28AraqEXetoC: try to replace 'type_' with 'typ'
17:03:53Araqoh hrm
17:03:56AraqI see
17:04:11Araqwell pas2nim doesn't support pascal's notion of OO
17:04:27Araqso ... what you want to accomplish looks like quite some work
17:06:53EXetoCok
17:07:39EXetoCmaybe I'll be brave enough to take on the C headers some time then
17:09:10Araqwell you can remove stuff from the pascal unit until it compiles :P
17:14:57*BitPuffin quit (Read error: Connection reset by peer)
17:15:21EXetoCso much stuff
17:17:49*Boscop joined #nimrod
17:18:30EXetoCautomation to the rescue
17:22:36Araqoh btw
17:22:41Araqare you wrapping gtk3?
17:22:48dom96well, I just spent 4 hours memtesting these RAM modules I got about a year ago.
17:23:00*dom96 sighs
17:25:10EXetoCAraq: yeah. he asked about it so I thought I'd give it a go
17:26:08AraqEXetoC: maybe it's better to start from the C headers; Pascal translations sometimes have new bugs
17:26:14Araqsad but true
17:29:54NimBotAraq/Nimrod master d104a9b Araq [+0 ±8 -0]: fixed and documented computedGoto pragma
17:29:54NimBotAraq/Nimrod master 83047c6 Araq [+0 ±1 -0]: GC: added static cycleGC checks
17:29:54NimBotAraq/Nimrod master bb90931 Araq [+0 ±3 -0]: implemented opcTypeTrait
17:29:54NimBotAraq/Nimrod master ad543d0 Araq [+4 ±23 -0]: Merge branch 'master' of github.com:Araq/Nimrod
17:30:02EXetoCok
17:30:08Araqbrb
17:35:58Araqback
17:43:18EXetoCI'll start off with this. can't inline be parsed? maybe these can be ignored too
17:43:54*Mat2 joined #nimrod
17:43:57Mat2hi @ all
17:44:52EXetoCI removed just the inline part and now it has been converted, but maybe it's a better idea to remove the whole declaration
17:44:56EXetoCMat2: hi
17:45:43Mat2hi EXetoC
17:45:53EXetoC"PGtkTextSearchFlags = ^TGtkTextSearchFlags; function forward_to_line_end: gboolean; cdecl; inline..."
17:47:03EXetoCwhich is preceded by a single-line declaration: "PPGtkTextSearchFlags = ^PGtkTextSearchFlags"
17:47:59EXetoCwill deal with this a little later
18:18:46*Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:18:53*Boscop quit (Disconnected by services)
18:29:16*Sergio965 joined #nimrod
19:19:07*Boscop joined #nimrod
20:02:28*Mat2 is now known as Mat2-coding
20:13:06*gradha joined #nimrod
20:19:21*Boscop quit (Disconnected by services)
20:32:00*EXetoC quit (Quit: WeeChat 0.4.1)
20:36:10*EXetoC1 joined #nimrod
20:36:14*EXetoC1 quit (Client Quit)
20:36:24*EXetoC joined #nimrod
21:09:36*Associat0r quit (Quit: Associat0r)
21:19:35*Boscop joined #nimrod
21:33:49*gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=OzrkmcBMPYo again)
21:44:55*Sergio965 quit (Ping timeout: 264 seconds)
21:51:19Mat2-codingI have declared a sequence in an object: seq[uint64]
21:52:27Mat2-codingnow I try to add a value to the sequence:
21:53:10Mat2-codingso for object x, sequence y for example: x.y.add (value)
21:53:40Mat2-codingthe result is- SIGSEGV: Illegal storage access. (Attempt to read from nil?)
21:55:00Araqwell initialize the seq to @[] first
21:55:23Mat2-codinghi Araq, thanks
21:56:53Mat2-codingok, so sequences are not initialized at default by declaration
21:57:10Mat2-coding(good to know)
21:57:38Araqthey are
21:57:45Araqbut the default value sucks :P
21:57:59Mat2-codingehm, ok *g*
21:58:06Araqyou can use 'safeAdd' or wait until we changed it
21:58:20Araqit's planned that 'add' can add to nil sequences
21:58:43Araqas it's indeed annoying and the single nil check won't kill us performance wise
21:59:58Mat2-codingthat would be nice indeed
22:05:48Mat2-codingwhat was the reason for handling initiation in these case so different ?
22:05:56EXetoCadd/unsafeAdd? so we still have both, just that the more common one is shorter
22:06:19Mat2-codingI mean in such a unexpected way
22:06:58AraqEXetoC: yeah I thought the same but I don't think 'xadd' is necessary (it's still not unsafe)
22:07:37AraqMat2-coding: my obsession with speed I guess
22:08:23Araqbut it's not really unexpected; the stdlib almost never handles 'nil' for speed/code size reasons
22:08:53Araqnow with the 'not nil' annotation we can ensure it statically
22:09:13Araqbut it'll be annoying sometimes *sigh*
22:10:54Mat2-codingthis behaviour can lead to some potential obscure runtime errors. Moreover the speed advantage is questionable in these case
22:11:00NimBotAraq/Nimrod master cb26bf7 Zahary Karadjov [+2 ±10 -0]: Experimental support for delayed instantiation of generics... 18 more lines
22:11:00NimBotAraq/Nimrod master d49423b Zahary Karadjov [+0 ±8 -0]: pass-through of static int generic params to arrays when late instantiation is disabled
22:11:08EXetoCI'd be happy with just having newSeq(s, 0) be the default implicit operation, which you could override with noInit, but it'd help in the case of the standard library if noInit could be part of a type alias
22:11:34EXetoCanyway, any change is fine
22:13:23EXetoCI think the current behavior is fine because of the helpful stack traces, but yeah it'll confuse newbies
22:13:52Araqzahary: what's "experimental support for delayed instantiation of generics"?
22:15:17Mat2-codingEXetoC: agree, it's a bit confusing at first
22:15:55Araqyou know ... "confusing at first" is not really concerning me that much :P
22:16:19zaharyAraq, check out the commit message
22:16:34zaharyand see the 2 added test cases
22:19:25*q66 quit (Quit: Leaving)
22:19:47*Boscop quit (Disconnected by services)
22:23:14Araqgah you changed evalTypeTraits
22:23:52Araqevals.nim is about to be replaced by vm.nim btw
22:24:39zaharyyeah, I noticed your commit
22:24:45zaharyit's not big deal - this is minor detail, we can change it later
22:25:42zaharyhow is the new VM performing btw? I noticed you haven't tried to implement C packing for the objects while they are in memory
22:26:04zaharyI still think that would be cool for easier FFI
22:26:24AraqI don't know yet
22:26:37AraqI only checked strutils.replace's performance
22:26:59Araqwhich does some array lookups etc.
22:27:14Araqwas a factor ~20 faster iirc
22:27:54zaharyimpressive, have you tried comparing it to a native version?
22:27:56Mat2-codinggood test in my opinion and nice archivement
22:28:20AraqI compared it to python with all the startup overheads
22:28:31Araqpython's replace is native C
22:28:51Araqwas 0.2s for Python and 0.8s for Nimrod iirc
22:29:25Araqso including system.nim compiling etc.
22:29:40Araqbut python does some crappy things at startup too I think
22:30:59Araqzahary: using a packed representation is very hard as macros need the real ASTs anyway
22:31:26Araqyou can do it by splitting the register sets
22:31:52Araqbut then you also need to deal with lower level pointers and soon may reimplement a GC for them
22:31:55dom96Araq: Why not just specify 'seq[T] not nil' for the 'add' proc, instead of doing a runtime nil check?
22:32:27Araqthe 'not nil' stuff is annoying as the compiler moans if it can't prove it IMHO anyway, dom96
22:32:51zaharywhat do you mean precisely. I took a look at the opcodes and it seems to me that the current slot indices could be replaced by offsets. do you mean that you still want the GC managed memory after the field is read and extracted from the packed object?
22:33:40dom96Araq: ok, I know the difference isn't much but could we have a 'nil' and 'not nil' version of the 'add' proc?
22:34:10dom96This way it will be optimised as long as the compiler can prove that the seq is not nil.
22:34:54Araqwell if we want to optimize we should do just that and not introduce yet another way to overload things based on minor type differences
22:35:31Araqbut it's likely you can't even measure the nil check anymore these days
22:35:38Araqso why bother
22:36:38Araqzahary: offset vs index is not the problem, the problem is that blobs don't cut it for modelling 'ref'
22:37:06*Sergio965 joined #nimrod
22:39:44zaharywell, only top-level objects will be allocated then (as blobs), refs within them will be marked from the metadata (you see where the offsets of the ref fields are)
22:40:08zaharyand more parts of the VM will have to work with ptr types
22:40:36Araqwell it's still lots of work to finish what I have
22:41:05Araqif we take the blob route, I may as well ask Mat2-coding to implement us a JIT :-)
22:41:33zaharythe FFI is still on the to-do, right?
22:41:48zaharyI mean, I haven't missed it in some new commit
22:41:50Araqyeah but that's not much work
22:42:30Araqin fact, this tracing JIT stuff seems reasonably easy to implement if it weren't for the nasty side exists
22:42:47Mat2-codingit is
22:46:11zaharyI think fast start is more important when it comes to macros. a JIT will add start-up delays. if we care for some very computationally intensive macros, I think the better solution will be to offer selective compilation to a DLL (can be controlled with a pragma).
22:46:16EXetoC"Error: conversion from int or Natural to int is invalid" interesting
22:46:40EXetoChas something like this been reported? it's related to type classes as you can see. will have to use separate overloads for now
22:46:52AraqEXetoC: report it
22:47:18*Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:48:42*Boscop joined #nimrod
22:49:28Araqzahary: true but on the other hand supporting the int,int8,int16,uint,uint32, etc. type zoo properly plus the blob stuff in a VM is lots of work
22:50:02Araqand the CPU already implements all these operations
22:50:23Araqso generating native code looks more and more attractive for the blob route
22:55:31*alexrp joined #nimrod
22:55:43Araqhi alexrp welcome
22:56:05Araqoh you're zor
22:56:14Araqwb then
22:56:25alexrpthanks :)
22:57:42*alexrp is now known as Zor
22:58:14Mat2-codingzahary: The JIT overhead can be reduced to great extense and such a design would even help reducing code complexity in my experience
22:58:28Mat2-codinghi Zor
23:03:12*Araq__ joined #nimrod
23:03:24Mat2-codingyou can't archive this with an orthodox JIT design however
23:03:31*Araq_ quit (Ping timeout: 264 seconds)
23:06:09*EXetoC quit (Quit: WeeChat 0.4.1)
23:13:30Araqzahary: fyi: http://www.1024cores.net/
23:16:22zaharyI've been here before :)
23:16:51Araqit's quite new for me :P
23:17:21Araqescaped me for some reason
23:23:54Mat2-codingget some sleep, ciao
23:24:06*Mat2-coding quit (Quit: Verlassend)
23:25:57Araqsame here, good night
23:48:55*Boscop quit (Disconnected by services)