| 00:03:50 | flaviu | I patched the compiler a while ago and it worked, but I vaguely remember noticing a potential bug. |
| 00:04:42 | filwit | yeah I worked through most of them, I'm re-running some of my old tests with the backed-up compiler to see what was wrong |
| 00:09:58 | * | hellonico joined #nim |
| 00:11:57 | Araq | a "Potential bug"? your patch was all wrong! |
| 00:12:16 | Araq | but I don't remember the details either :P |
| 00:17:43 | filwit | hmm.. as var as I can tell my code was working well actually, I just never finished distinguishing between a call with a single parameter and a type-conversion |
| 00:19:47 | filwit | I think I read about 'destroy' and thought that might be a more painless and correct way implementing constructors as well |
| 00:20:45 | filwit | for one, having a proc name be the same as a type means `module.Foo` is ambiguous without a context (which is doable, but perhaps not ideal) |
| 00:21:18 | flaviu | filwit: You could remove type conversions from the compiler completely. |
| 00:21:21 | * | Sembei joined #nim |
| 00:21:34 | * | Varriount_ joined #nim |
| 00:22:46 | filwit | flaviu: I'm actually not opposed to that, for other reasons, but I still think making a `proc create(f:var Foo) = ...` is the best syntax for construction to some degree |
| 00:23:33 | filwit | it also feels similar to `destroy`, and considering they're both related to a variables memory behavior, that feels right to me |
| 00:23:40 | * | Varriount quit (Ping timeout: 256 seconds) |
| 00:23:46 | Araq | remove type conversions from the compiler completely? o.O |
| 00:23:56 | Araq | how do you bootstrap then? |
| 00:24:15 | Araq | or expect your "patch" to be ever merged? |
| 00:24:45 | filwit | i was thinking about converters, not type conversion in it's entirety... but I also said that without much thought |
| 00:25:01 | flaviu | Put type conversions in system |
| 00:26:57 | filwit | wait what am I talking about... i *use* converters in my math libs... |
| 00:28:13 | * | TEttinger joined #nim |
| 00:29:21 | filwit | and I like converters, and I like the type-conversion syntax as it is (i think it's simple and makes sense)... there isn't even a problem in with type-conversion syntax and constructors the way I had done it before, I just didn't complete it, and I think `create` makes more sense |
| 00:30:07 | flaviu | Create has a disadvantage though, you can't call it Foo and return a Bar. |
| 00:30:19 | flaviu | ie, proc Foo(): Bar |
| 00:30:38 | flaviu | or perhaps proc Foo(): BarTypeclass |
| 00:30:45 | flaviu | err, FooTypeclass |
| 00:31:44 | filwit | that's could easily be considered not an advantage.. and in my original post on the forums I address this: for factories you want associated with a type, just make the proc take in the type as a first param, eg: |
| 00:31:59 | filwit | proc cached(t:type Foo, ...): Bar = |
| 00:32:14 | filwit | var b = Foo.cached(..) |
| 00:32:24 | filwit | var f = Foo() |
| 00:32:42 | onionhammer | also you can still create a Foo without using the constructor |
| 00:33:00 | Araq | the point of the "factory" argument is that things usually don't start as a factory but might evolve into one. not sure if that's solved here |
| 00:33:29 | onionhammer | Araq just make it so module authors can prevent instantiation of types outside the module ;) |
| 00:35:04 | filwit | Araq: that doesn't seem like much of a point really? I mean, what scenerio do you want to do that in and not be able to also update the use-case code to use the named factory instead? |
| 00:35:27 | filwit | er.. that was confusingly written, sorry |
| 00:36:19 | Araq | filwit: all the time. |
| 00:36:38 | Araq | because I don't want to break client code |
| 00:37:32 | Araq | onionhammer: so how does that work in practice? is seq[Foo] still allowed? can I setLen a sequence? |
| 00:37:51 | filwit | I'm not saying I know there isn't any scenario where that happens, I'm just not aware of any. "It would break the clients code" doesn't make a ton of sense really, cause by changing the return type you'd either have to conform the existing interface, or you'd break their code anyways. |
| 00:38:14 | flaviu | hmm, create:TypeclassFoo would still work, and I'd be able to return a concrete type. |
| 00:40:10 | filwit | flaviu: you mean `proc create(f:SomeFoo) = ...` which gets called for anything matching the type-class? That would be cool.. but I'm not sure what it would mean checking every type-class for every object construction.. |
| 00:40:34 | flaviu | no, proc create(...): TypeclassFoo = FooImpl(123) |
| 00:41:02 | filwit | that's not really how I was proposing 'create' work |
| 00:41:18 | filwit | 'create' doesn't return anything, it works with a var parameter |
| 00:42:51 | filwit | the reason is, by default (although you can prevent it with a pragma), the 'create' proc gets called after allocation (so the constructor doesn't need to deal with it) |
| 00:44:47 | flaviu | IMO adding extra knobs is bad design. Things should be designed for maximum flexibility from the start. |
| 00:45:19 | flaviu | knob <=> pragma |
| 00:47:15 | onionhammer | Araq yeah, you can still allocate sizeof(Foo) |
| 00:47:34 | * | reem joined #nim |
| 00:48:12 | filwit | well the argument here is that currently constructors are already available to every type, and they allocate depending on type-info (stack or heap).. so we just extend that behavior, and make a needed override pragma to control specific types who's "default" allocation we want to override |
| 00:48:20 | filwit | flaviu ^ |
| 00:49:56 | filwit | we honestly need an extra "something" to control how constructors in there current form work right now.. sometimes a type doesn't want a default constructor as an option, and others want to allocate outside of the default |
| 00:50:08 | filwit | my proposal address all that |
| 00:50:31 | flaviu | filwit: Do you have some document typed up with it? |
| 00:50:36 | filwit | but it does so in a way that keeps the convenience |
| 00:52:03 | flaviu | I suppose I might be arguing for the language I want, not for what's consistent with the rest of Nim. |
| 00:52:06 | filwit | flaviu: I wrote on the forums a bunch starting on this page: http://forum.nim-lang.org/t/703/6 |
| 00:52:41 | filwit | flaviu: Araq asked me to make a NEC, but I'm thinking I'm going to play around with code first, then make one with a more concrete understanding of how to do it |
| 00:53:19 | Araq | it's called a NEP, but yes |
| 00:53:28 | filwit | right |
| 00:54:15 | flaviu | minor style concern: 'proc create(f: var Foo, bar: int)' -> 'proc create(self: var Foo, bar: int)', For consistency with typical parameter naming. |
| 00:54:53 | filwit | flaviu: that's your choice, it's up to the author there |
| 00:55:40 | filwit | personally I've always favored 'this' but recently 'me' is starting to grow on me :) |
| 00:57:30 | * | hellonico quit (Remote host closed the connection) |
| 00:57:39 | flaviu | filwit: I don't care about a specific name, but my goal here is to get the reader to think in a certain way. |
| 00:58:15 | filwit | flaviu: oh you mean for my NEP, I understand. Sure, will use 'self' then. |
| 00:58:22 | filwit | going to eat. bbl |
| 00:59:51 | * | xxx quit (Ping timeout: 250 seconds) |
| 01:00:32 | * | hellonico joined #nim |
| 01:01:22 | Araq | good night |
| 01:01:26 | * | hellonico quit (Remote host closed the connection) |
| 01:02:01 | * | rektide quit (Ping timeout: 250 seconds) |
| 01:03:02 | * | rektide joined #nim |
| 01:06:10 | * | xxx joined #nim |
| 01:12:53 | renesac | I thought things like "len" on non-intialized seqs was safe now |
| 01:14:37 | renesac | there isn't anything like python defaultdict in nim, right? |
| 01:18:25 | def- | renesac: i also thought so, maybe it was reverted? |
| 01:19:01 | * | brson joined #nim |
| 01:19:32 | renesac | with "cDict[cur].len == 0" I get a SIGSEGV, but with "cDict.hasKey(cur)" it executes correctly |
| 01:20:02 | def- | yes, i tried and len definitely doesn't work on nil seqs |
| 01:20:09 | renesac | the latter is better anyway |
| 01:20:19 | renesac | for this case |
| 01:21:36 | renesac | *there is a "not" before the last example |
| 01:22:00 | fowlmouth | i tried to make add/len work for nil strings and seqs, i ran into problems for what order they are in |
| 01:22:30 | renesac | order? |
| 01:22:52 | fowlmouth | order defined in system.nim |
| 01:25:08 | renesac | I don't fully understand, but ok if it is unsolvable.... |
| 01:25:21 | renesac | I don't know what order has to do with the lenght of something |
| 01:26:12 | renesac | and I don't find the definition of order in system.nim |
| 01:33:05 | * | Trixar_za joined #nim |
| 01:35:49 | * | saml_ joined #nim |
| 01:36:53 | * | BitPuffin quit (Ping timeout: 248 seconds) |
| 01:43:56 | * | hellonico joined #nim |
| 01:46:39 | * | Trixar_za quit (Quit: Leaving) |
| 01:59:35 | * | mwbrown joined #nim |
| 02:00:27 | renesac | there is no sort() defined for strings in nim stdlib... |
| 02:02:56 | * | untitaker quit (Ping timeout: 250 seconds) |
| 02:04:06 | fowlmouth | renesac, sort takes a function and there is a special system.cmp for strings |
| 02:04:30 | fowlmouth | .eval echo cmp("a","b") |
| 02:04:32 | Mimbus | fowlmouth: -1 |
| 02:04:51 | renesac | the cmp should be for chars |
| 02:05:04 | fowlmouth | the generic cmp works fine for chars |
| 02:05:05 | renesac | but yeah, I forgot to give the cmp argument |
| 02:05:23 | fowlmouth | .eval echo cmp('a','b') |
| 02:05:25 | Mimbus | fowlmouth: -1 |
| 02:07:12 | renesac | aand there is no join for 'openarray[char]' |
| 02:07:20 | renesac | let's go back to the string |
| 02:07:42 | renesac | I just hope it don't put the '/0' at the front |
| 02:08:44 | renesac | I will make some pull requests when I finish this |
| 02:09:18 | * | untitaker joined #nim |
| 02:11:49 | * | reem quit (Remote host closed the connection) |
| 02:12:04 | renesac | strings don't seem to fit in openarray[T] |
| 02:12:16 | renesac | as I suspected |
| 02:12:38 | * | reem joined #nim |
| 02:14:48 | * | reem quit (Remote host closed the connection) |
| 02:15:01 | * | jholland quit (Quit: Connection closed for inactivity) |
| 02:16:21 | * | ChrisMAN quit (Ping timeout: 248 seconds) |
| 02:19:26 | renesac | how can I cast a slice of a string as an seq? |
| 02:19:35 | renesac | or is this impossible? |
| 02:22:03 | fowlmouth | renesac, when you take a slice of a seq it allocates a new seq |
| 02:22:18 | renesac | :/ |
| 02:22:53 | renesac | so the in place slice didn't went anywhere |
| 02:23:12 | renesac | in this time I was away |
| 02:23:22 | fowlmouth | not sure what you mean |
| 02:23:58 | renesac | a slice like D slices, but with an extra pointer to not confuse the GC |
| 02:25:07 | fowlmouth | no that isnt a thing |
| 02:25:25 | * | wb quit (Ping timeout: 248 seconds) |
| 02:26:44 | renesac | so no way to use openarray[T] procs for strings... |
| 02:27:05 | renesac | or actually, the /0 is beyond the end of the string |
| 02:27:11 | renesac | so I shouldn't need the slice |
| 02:27:26 | renesac | just a way to cast it to a seq[char] |
| 02:27:34 | fowlmouth | renesac, why dont you just use seq[char] |
| 02:27:51 | renesac | because I need a string at the end |
| 02:28:40 | renesac | and I tried to use it but there is no join() defined for that, so I have to implement some missing proc anyway |
| 02:29:03 | renesac | and doing it directly with strings avoids one superfulous allocation |
| 02:29:24 | * | darkf joined #nim |
| 02:31:11 | fowlmouth | ok |
| 02:32:08 | renesac | so, nim won't let me cast to seq[char] |
| 02:32:46 | renesac | oh |
| 02:32:48 | renesac | now I got it |
| 02:33:00 | fowlmouth | you did? |
| 02:33:47 | renesac | Error: type mismatch: got (seq[char], proc (char, char): int{.gcsafe, locks: 0.}) |
| 02:33:47 | renesac | but expected one of: |
| 02:33:47 | renesac | algorithm.sort(a: var openarray[T], cmp: proc (T, T): int{.closure.}, order: SortOrder) |
| 02:34:09 | renesac | not a closure? |
| 02:34:34 | fowlmouth | this is sort in-place |
| 02:34:40 | fowlmouth | it requires a mutable seq/array |
| 02:34:54 | renesac | s is mutable |
| 02:35:04 | renesac | maybe because I used cast? |
| 02:35:33 | fowlmouth | do you pass a sort order |
| 02:35:50 | renesac | nope, it should have a default argument.. |
| 02:36:06 | fowlmouth | renesac, yea using cast there would be incorrect |
| 02:36:41 | renesac | why? |
| 02:36:53 | renesac | ok, because cast don't return a var T |
| 02:37:01 | fowlmouth | cast[int](s) # s is an R value |
| 02:37:07 | fowlmouth | er the int resulting is an R value |
| 02:37:51 | renesac | can a mcast[]() be made? |
| 02:38:43 | * | saml_ quit (Read error: Connection reset by peer) |
| 02:38:47 | renesac | the result of that cast is a pointer right? |
| 02:39:02 | fowlmouth | what cast? |
| 02:39:28 | fowlmouth | cast[int](s) # result is int |
| 02:39:57 | fowlmouth | i feel like if i help you with this it will give me negative karma |
| 02:40:52 | fowlmouth | but oh well |
| 02:41:32 | fowlmouth | .eval var s = "Hello"; (cast[var seq[string]](addr s))[1] = 'E'; echo s |
| 02:41:33 | Mimbus | fowlmouth: eval.nim(4, 37) Error: type mismatch: got (char) but expected 'string' |
| 02:41:42 | fowlmouth | .eval var s = "Hello"; (cast[var seq[char]](addr s))[1] = 'E'; echo s |
| 02:41:44 | Mimbus | fowlmouth: HEllo |
| 02:41:52 | EXetoC | and sequences have a header |
| 02:41:58 | fowlmouth | renesac, ^ |
| 02:42:18 | renesac | strings don't have the same header? |
| 02:42:34 | fowlmouth | they do |
| 02:43:24 | EXetoC | um yeah |
| 02:44:53 | renesac | SIGSIEGV somewhere now |
| 02:45:09 | renesac | XD |
| 02:45:59 | renesac | well, w/o the sort line, it enters a infinite loop |
| 02:46:04 | fowlmouth | you are asking for segfaults with what you're doing |
| 02:46:24 | fowlmouth | lol |
| 02:46:28 | * | hellonico quit (Remote host closed the connection) |
| 02:47:00 | renesac | if there was a pre-made alternative I would use it |
| 02:47:01 | renesac | :P |
| 02:47:44 | * | saml_ joined #nim |
| 02:47:48 | fowlmouth | the solution is simple renesac |
| 02:47:53 | fowlmouth | work with seq[string], return a string |
| 02:48:10 | fowlmouth | er seq[char] or whatever |
| 02:48:28 | renesac | I'm doing that because python started being too slow |
| 02:48:37 | renesac | *that in nim |
| 02:49:11 | renesac | seq[string] would work smoothly, but OMG the superfulous allocations |
| 02:49:38 | renesac | as I said, I would need to implement a join() for seq[char] (pretty trivial) |
| 02:50:12 | renesac | but the solution would have one extra allocation |
| 02:50:28 | renesac | and I didn't tought adapting the sort would be so difficult |
| 02:50:35 | fowlmouth | what are you doing anyways |
| 02:51:44 | renesac | figuring out how to represent words unambiously using the minimal number of characters from it |
| 02:52:07 | renesac | I could also define a new type and a cmp() for that |
| 02:52:14 | renesac | instead of sorting |
| 02:52:37 | renesac | but I don't thing it would be better |
| 02:52:41 | renesac | *think |
| 02:52:55 | fowlmouth | well better to get it working then optimize it later |
| 02:53:02 | fowlmouth | imo |
| 02:53:09 | renesac | it is already working in python |
| 02:53:12 | renesac | ^^' |
| 02:53:26 | renesac | but yeah, I also wanted that |
| 02:53:36 | renesac | that is why I tried using seq[char] |
| 02:54:08 | renesac | I will see what is my infinite loop |
| 02:54:18 | renesac | then see if the sort() is really doomed |
| 02:54:42 | renesac | if so, or I do some insertion sort or I implement the join() |
| 02:55:08 | renesac | but ideally I could use sorting for seqs on strings... |
| 02:56:49 | * | fowlmouth quit (Quit: Leaving) |
| 02:57:17 | * | fowl joined #nim |
| 03:01:17 | * | MagusOTB joined #nim |
| 03:16:40 | * | mwbrown quit (Ping timeout: 244 seconds) |
| 03:40:01 | * | reem joined #nim |
| 03:42:28 | * | hellonico joined #nim |
| 04:01:14 | * | Infathome joined #nim |
| 04:04:20 | * | Infathome left #nim ("Leaving") |
| 04:08:28 | * | darkf_ joined #nim |
| 04:11:37 | * | darkf quit (Ping timeout: 265 seconds) |
| 04:17:42 | * | gsingh93 quit (Ping timeout: 250 seconds) |
| 04:20:29 | * | brson quit (Quit: leaving) |
| 04:20:50 | * | brson joined #nim |
| 04:24:28 | * | reem quit (Remote host closed the connection) |
| 04:26:12 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 04:27:20 | * | johnsoft joined #nim |
| 04:28:43 | * | reem joined #nim |
| 04:33:24 | * | BlaXpirit joined #nim |
| 04:34:39 | * | darkf_ is now known as darkf |
| 04:42:32 | * | gsingh93 joined #nim |
| 04:46:12 | * | eventualbuddha quit (Read error: Connection reset by peer) |
| 04:46:14 | * | DecoPerson quit (Read error: Connection reset by peer) |
| 04:46:36 | * | mikolalysenko quit (Ping timeout: 272 seconds) |
| 04:47:21 | * | DecoPerson joined #nim |
| 04:47:21 | * | eventualbuddha joined #nim |
| 04:47:38 | * | CARAM__ quit (Ping timeout: 252 seconds) |
| 04:49:03 | * | mikolalysenko joined #nim |
| 04:49:26 | * | CARAM__ joined #nim |
| 04:54:50 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 04:56:12 | * | johnsoft joined #nim |
| 05:06:44 | * | saml_ quit (Remote host closed the connection) |
| 05:07:26 | * | reem_ joined #nim |
| 05:11:17 | * | reem quit (Ping timeout: 248 seconds) |
| 05:21:34 | * | wb joined #nim |
| 05:35:15 | * | HakanD____ joined #nim |
| 05:42:56 | * | HakanD____ is now known as HakanD |
| 05:45:41 | * | reem_ quit (Ping timeout: 256 seconds) |
| 05:47:57 | * | Omnivore joined #nim |
| 05:50:27 | Omnivore | just dropping in to comment in re wikipedia article deletion; seems to me its more of a question of wikipedia's relevance than nim's notability - they're caught it the cracks of a paradigm shift |
| 05:50:45 | Omnivore | anyhow, looking forward to 1.0 and will check back then, good luck all |
| 05:51:35 | * | Omnivore left #nim (#nim) |
| 05:59:03 | * | wink-s quit (Quit: Page closed) |
| 06:00:27 | * | nande quit (Remote host closed the connection) |
| 06:06:59 | * | brson quit (Quit: leaving) |
| 06:11:03 | * | HakanD_ joined #nim |
| 06:14:57 | * | HakanD quit (Ping timeout: 264 seconds) |
| 06:41:13 | * | BlaXpirit quit (Ping timeout: 256 seconds) |
| 07:07:46 | * | BlaXpirit joined #nim |
| 07:11:09 | * | Ven joined #nim |
| 07:25:06 | * | reem joined #nim |
| 07:34:24 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 07:38:30 | * | yglukhov_ joined #nim |
| 07:42:51 | * | yglukhov_ quit (Ping timeout: 250 seconds) |
| 07:52:52 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 07:55:06 | * | gsingh93 quit (Ping timeout: 246 seconds) |
| 07:55:58 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 08:11:23 | * | Ven joined #nim |
| 08:15:30 | * | reem quit (Remote host closed the connection) |
| 08:17:29 | * | davidhq joined #nim |
| 08:28:04 | * | dewdrop joined #nim |
| 08:35:37 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:38:42 | * | davidhq joined #nim |
| 08:39:21 | * | davidhq quit (Client Quit) |
| 08:40:02 | * | davidhq joined #nim |
| 08:43:04 | * | yglukhov_ joined #nim |
| 08:44:37 | * | davidhq quit (Ping timeout: 248 seconds) |
| 08:53:01 | * | meeeee joined #nim |
| 08:53:37 | meeeee | do i have to download iup lib / where? |
| 08:53:48 | meeeee | Error: cannot open 'lib/niup' |
| 08:54:25 | meeeee | and is iup recom for gui? |
| 08:58:09 | meeeee | i want to make a window with a gridlist, with two icons in each row, and a few buttons, checkboxes. create transparent png icons with gradients, rotated text... possible? |
| 08:59:11 | meeeee | its half done (doing its job), but i would like to use the opportunity to write it in nim |
| 09:01:01 | meeeee | unless im stuck .. because i can do it very quickly in another lang and dont like to be stuck .. |
| 09:01:09 | meeeee | anyone? |
| 09:02:05 | meeeee | nimble? |
| 09:10:32 | meeeee | jesus |
| 09:10:34 | meeeee | im out |
| 09:10:48 | meeeee | nimble up and running but no iup |
| 09:10:54 | meeeee | search iup no |
| 09:10:58 | meeeee | install iup no |
| 09:13:00 | meeeee | anyone? |
| 09:13:16 | meeeee | last minute before quitting nim |
| 09:13:30 | * | milosn quit (Ping timeout: 256 seconds) |
| 09:14:48 | meeeee | send mail to [email protected] if you want me to code in nim. will check once in a few hours. good bye and good luck |
| 09:14:54 | * | meeeee quit (Quit: meeeee) |
| 09:17:42 | pigmej | lol? |
| 09:23:05 | * | reem joined #nim |
| 09:24:41 | * | hellonico quit (Remote host closed the connection) |
| 09:25:08 | filwit | lol wtf... |
| 09:25:09 | * | hellonico joined #nim |
| 09:27:40 | * | reem quit (Ping timeout: 256 seconds) |
| 09:27:49 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:29:42 | * | hellonico quit (Ping timeout: 272 seconds) |
| 09:35:25 | * | johnsoft joined #nim |
| 09:43:54 | federico3 | note to self: never give whiskey to meeeee anymore |
| 10:00:33 | * | Kingsquee quit (Quit: Konversation terminated!) |
| 10:07:55 | * | HakanD_ quit (Quit: Be back later ...) |
| 10:12:47 | * | milosn joined #nim |
| 10:17:29 | * | HakanD_ joined #nim |
| 10:21:43 | * | Trustable joined #nim |
| 10:25:18 | * | milosn quit (Read error: Connection reset by peer) |
| 10:26:10 | * | milosn joined #nim |
| 10:32:18 | dom96 | lol |
| 10:33:11 | pigmej | shall we recommend snickers for him ? |
| 10:44:23 | * | HakanD_ quit (Read error: Connection reset by peer) |
| 10:44:36 | * | HakanD_ joined #nim |
| 10:50:01 | * | milosn quit (Read error: Connection reset by peer) |
| 10:52:09 | * | MyMind joined #nim |
| 10:52:58 | federico3 | or sticking to php and nodejs |
| 10:53:04 | pigmej | ;D |
| 10:53:26 | dtscode | ew |
| 10:53:46 | * | wan quit (Ping timeout: 250 seconds) |
| 11:01:24 | federico3 | unrelated: seqdiag and blockdiag are nice http://blockdiag.com/en/index.html (but currently in Python only) |
| 11:02:05 | * | Ven joined #nim |
| 11:05:21 | * | polde quit (Ping timeout: 265 seconds) |
| 11:07:35 | * | wan joined #nim |
| 11:07:44 | dtscode | i like this |
| 11:08:24 | * | milosn joined #nim |
| 11:15:06 | federico3 | there are adaptors for Sphinx to put small diagrams in code documentation |
| 11:16:28 | HakanD_ | that was interesting (: |
| 11:23:13 | * | a5i quit (Quit: Connection closed for inactivity) |
| 11:27:49 | * | TEttinger quit (Ping timeout: 248 seconds) |
| 11:32:33 | * | polde joined #nim |
| 11:46:29 | * | milosn quit (Ping timeout: 248 seconds) |
| 11:56:04 | * | Ven quit (Ping timeout: 255 seconds) |
| 12:01:49 | * | Ven joined #nim |
| 12:20:33 | * | BlaXpirit joined #nim |
| 12:34:07 | * | milosn joined #nim |
| 12:41:39 | * | gokr joined #nim |
| 12:46:48 | * | gokr quit (Read error: Connection reset by peer) |
| 12:47:47 | * | milosn quit (Ping timeout: 252 seconds) |
| 12:52:29 | * | milosn joined #nim |
| 12:54:52 | * | gokr joined #nim |
| 12:56:01 | * | a5i joined #nim |
| 12:59:13 | * | coopernurse joined #nim |
| 12:59:13 | * | gokr quit (Read error: Connection reset by peer) |
| 13:00:25 | * | Varriount_ quit (Ping timeout: 264 seconds) |
| 13:01:43 | coopernurse | Hi folks. I'm building a nim docker image and want to slim it down. After building Nim do I need to keep the Nim/csources, compiler, lib, or tests directories? |
| 13:01:53 | * | BitPuffin joined #nim |
| 13:01:59 | coopernurse | I know some of those directories (lib?) are required for the nim compiler right? |
| 13:03:43 | * | mpthrapp joined #nim |
| 13:05:12 | * | gokr joined #nim |
| 13:05:24 | dom96 | coopernurse: You don't need csources or the tests. |
| 13:05:38 | dom96 | Some projects may depend on the compiler files. |
| 13:05:53 | dom96 | I would keep it |
| 13:05:59 | coopernurse | great, thanks. csources is the big one. that will save 172MB |
| 13:07:20 | * | gokr quit (Read error: Connection reset by peer) |
| 13:24:32 | * | filwit quit (Quit: Leaving) |
| 13:26:11 | * | pafmaf joined #nim |
| 13:36:22 | coopernurse | Ok, docker image is available if anyone wants to use it. https://github.com/coopernurse/docker-nim |
| 13:48:37 | * | milosn quit (Ping timeout: 248 seconds) |
| 13:50:26 | * | banister joined #nim |
| 13:51:18 | * | banister is now known as banisterfiend |
| 13:55:28 | * | Matthias247 joined #nim |
| 14:13:26 | * | polde quit (Ping timeout: 272 seconds) |
| 14:14:55 | * | polde joined #nim |
| 14:23:44 | arnetheduck | Araq, https://github.com/Araq/Nim/pull/2428 rebased & ready |
| 14:24:17 | Araq | +1 for poking me :-) |
| 14:25:32 | dtscode | coopernurse, awesome :D |
| 14:27:53 | Araq | arnetheduck: newStringOfCap(int(s.len.toFloat * 1.1) + 1) good guess? measure somehow? |
| 14:27:58 | Araq | *measured? |
| 14:32:36 | arnetheduck | no. gut feeling.. has worked well for me in other similar situations.. splitting it into 64-byte parts gets you 67 for every 64 bytes, plus a little more.. +2 would maybe work better for small strings, now that I think about it, not sure if nsoc has a min allocation size? |
| 14:35:32 | Araq | "nsoc"? |
| 14:35:43 | arnetheduck | newStringOfCAp |
| 14:36:12 | Araq | so ... your new equals file doesn't compute the CRC at all anymore? |
| 14:36:13 | arnetheduck | too used to those smart search boxes :) |
| 14:36:36 | * | wan quit (Ping timeout: 244 seconds) |
| 14:37:20 | arnetheduck | no.. you still have to make full passes over both file & rope data, so I'd say it makes more sense comparing it than computing two values and then comparing them |
| 14:38:04 | Araq | yeah but I had my reasons for using a CRC here. |
| 14:38:29 | arnetheduck | you didn't document them, and I couldn't think of one :) |
| 14:39:16 | Araq | well it should be somewhat faster for the common case where they are equal |
| 14:39:32 | arnetheduck | what, crc or compare? |
| 14:39:37 | Araq | crc |
| 14:39:53 | arnetheduck | why? |
| 14:40:09 | Araq | streaming works better |
| 14:40:19 | * | wb quit (Ping timeout: 255 seconds) |
| 14:41:20 | arnetheduck | for a fragmented rope? |
| 14:43:40 | Araq | when you don't have to compare a rope against a file buffer there is more space left in the caches |
| 14:43:57 | Araq | but I never did any measurements |
| 14:44:01 | Araq | ;-) |
| 14:45:19 | Araq | if (i >= length) or frmt[i] notin {'0'..'9'}: # fine with me, but not required |
| 14:45:48 | Araq | if i == length then frmt[i] == '\0' and so it's not in '0'..'9' |
| 14:46:23 | * | Araq likes the terminating zero |
| 14:50:00 | * | wan joined #nim |
| 14:50:01 | arnetheduck | oh, so accessing string[string.len] is ok? |
| 14:50:24 | Araq | yes |
| 14:51:04 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 14:52:34 | arnetheduck | ooh. unusual |
| 14:53:50 | arnetheduck | I'll remove it then |
| 15:00:27 | arnetheduck | original code, if I add 1000 comparisons (crc): Hint: operation successful (83336 lines compiled; 107.462 sec total; 241.247MB; Release Build) [SuccessX] |
| 15:00:51 | arnetheduck | mine (direct compare): Hint: operation successful (83373 lines compiled; 69.485 sec total; 237.243MB; Release Build) [SuccessX] |
| 15:02:34 | def- | arnetheduck: did you clean the nimcache and make sure disk cache is cleared before? |
| 15:03:26 | arnetheduck | I'm using the second stage of koch boot, so both results are with full nimcache, without cc phase |
| 15:03:51 | def- | that's a nice speedup then |
| 15:04:21 | arnetheduck | no, it's not noticable - we only compare once, not 1000 times as I did for the benchmark :) |
| 15:05:58 | * | wan quit (Ping timeout: 256 seconds) |
| 15:06:18 | * | wan joined #nim |
| 15:09:11 | arnetheduck | http://pastebin.com/4AXry9cS |
| 15:12:09 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:13:30 | arnetheduck | it's also possible that the files are so small that file and rope fragments comfortably fit in some cache, and therefore the streaming effect doesn't matter.. |
| 15:13:43 | * | darkf quit (Quit: Leaving) |
| 15:14:19 | Araq | hey don't quote me on that. "streaming effect" might not be a thing that exists |
| 15:18:41 | renesac | the regular comparison is still streaming two pieces of data, isnt't it? |
| 15:19:06 | renesac | instead of one a time in the CRC case |
| 15:19:32 | * | mpthrapp quit (Read error: Connection reset by peer) |
| 15:20:47 | Araq | dom96: is it too late to remove the dot for nimble on windows? |
| 15:21:22 | Araq | in fact, I would remove it on unix too. that thing should not be hidden |
| 15:21:58 | arnetheduck | there, length check removed |
| 15:22:28 | dom96 | Araq: it's configurable |
| 15:22:44 | dom96 | IMO it should be hidden |
| 15:22:47 | def- | Araq: i believe on unix it should be hidden, just because it's common to do so (not that I find that very reasonable) |
| 15:23:10 | pigmej | +1 for hidden |
| 15:23:21 | arnetheduck | oh, there's few more |
| 15:24:59 | * | wink-s joined #nim |
| 15:27:01 | * | mpthrapp joined #nim |
| 15:27:13 | Araq | dom96: so how can I override it? |
| 15:28:45 | * | wan quit (Ping timeout: 252 seconds) |
| 15:30:09 | * | wan joined #nim |
| 15:31:11 | arnetheduck | there, all extra length checks removed, I think |
| 15:32:03 | Araq | I already merged :P |
| 15:32:50 | * | Demos joined #nim |
| 15:32:52 | federico3 | I have an async procedure that should keep a "status" of some sort. I tried creating an object and passing it to the proc as a var argument but it triggers an illegal capture. How should I implement this? |
| 15:33:16 | federico3 | (I need #nim-noobs) |
| 15:33:31 | EXetoC | def-: it is since few apps relies on .config |
| 15:35:26 | def- | EXetoC: well, .config sounds weird for storing nimble packages |
| 15:36:25 | renesac | so, " proc foo(s: var string) = echo cast[var seq[char]](s) " fails |
| 15:36:33 | renesac | I thought strings were more compatible with seqs |
| 15:38:13 | EXetoC | def-: I guess. there are only two conventions though |
| 15:38:48 | renesac | ok, w/o the "var" it works, but I need to pass a "var seq[char]" |
| 15:39:34 | * | MagusOTB quit (Ping timeout: 264 seconds) |
| 15:40:33 | * | Ven joined #nim |
| 15:40:38 | EXetoC | why not just extend the interface? |
| 15:41:36 | renesac | I'm trying to use algorithm.sort() |
| 15:41:42 | renesac | well, maybe I should edit it |
| 15:41:59 | renesac | I was going for a simple insertion sort though... for my use case it is plenty |
| 15:44:06 | arnetheduck | btw, if, in the ropes.~ template, I replace ropef with rope (which makes more sense, imo), I get lots of compile fails in the generated c code... any ideas? |
| 15:44:54 | def- | renesac: i think concepts would really help in making the standard library more general, I've also written a bit here: https://github.com/Araq/Nim/pull/2449 |
| 15:45:54 | renesac | def-: have you read about D ranges? |
| 15:45:58 | Demos | def-: in general I think that concepts should not be needed to make anything more general. As far as I can tell they just improve error messages |
| 15:46:34 | arnetheduck | in fact, so many that koch hangs.. it looks like gcc gets blocked because it's stuck and not doing anything... compiler call in nim reads buffers while calling compiler, or just one big read at the end? intuitively it's blocked because it's run out of pipe buffer |
| 15:47:37 | EXetoC | Demos: sounds like a good reason to me. also, it makes it easier to reason about the interface |
| 15:47:56 | Demos | yeah it does |
| 15:48:03 | renesac | InputRange: requires the empty, front and popFront() member functions |
| 15:48:03 | renesac | ForwardRange: additionally requires the save member function |
| 15:48:03 | renesac | BidirectionalRange: additionally requires the back and popBack() member functions |
| 15:48:03 | renesac | RandomAccessRange: additionally requires the [] operator (and another property depending on whether the range is finite or infinite) |
| 15:48:17 | renesac | <-- types of D ranges |
| 15:48:18 | Demos | and you get to prune off types that work but don't do what you expect |
| 15:48:43 | Demos | wrt to pairs though I think you are gunna need a different impl for hash maps and sequences |
| 15:48:48 | renesac | I think it makes a lot of sense to use concepts to make algorithms more general |
| 15:48:57 | renesac | http://ddili.org/ders/d.en/ranges.html |
| 15:49:00 | * | milosn joined #nim |
| 15:49:33 | EXetoC | renesac: it would get ugly because of the inability to declare a constant in an object |
| 15:50:11 | renesac | a constant should be part of it's type signature |
| 15:50:18 | EXetoC | anyway, the error messages would still not be as good as they could be |
| 15:50:21 | renesac | what people do with fixed size matrixes. etc? |
| 15:50:32 | Demos | renesac: those look like they are essentially c++ iterator concepts |
| 15:50:38 | Demos | renesac: they don't |
| 15:50:45 | EXetoC | renesac: you can query that outside the type definition? |
| 15:50:48 | Demos | like you need static[T] to do that well |
| 15:50:54 | Demos | and static[T] does not work |
| 15:51:07 | renesac | :/ |
| 15:51:17 | Demos | so we do what everyone except C++ does and just have specific named functions or use dynamic size most of the time |
| 15:51:29 | renesac | Demos: yeah, it is based on C++ iterators, but a bit more organized |
| 15:51:35 | Demos | well yeah |
| 15:51:58 | renesac | so a function can require a RandomAccessRange |
| 15:52:00 | renesac | I think |
| 15:52:14 | renesac | (it's been sometime since I last programmed in D) |
| 15:53:15 | * | ChrisMAN joined #nim |
| 15:58:04 | renesac | aparently they only require a range, and compilation fails if some of the procs required are not present |
| 15:58:25 | renesac | they specify what type of range is needed in the docs |
| 15:58:38 | renesac | nim could do better |
| 15:58:47 | renesac | with concepts |
| 15:59:03 | renesac | openarray is already a concept |
| 15:59:11 | renesac | only a bit restrictive |
| 16:00:39 | EXetoC | yes: "void foo(R)(R range) if (isInputRange!R) { .. } |
| 16:00:44 | * | wb joined #nim |
| 16:00:50 | Demos | I thought openarrays were a real type |
| 16:00:59 | EXetoC | it's only for parameters |
| 16:01:07 | Demos | or do you mean opearray is a concept for openarray[T] for all T |
| 16:01:26 | Demos | Right, but I am pretty sure they have a size |
| 16:01:29 | EXetoC | it's alright. it's just that if the check is wrong in any way then you might have errors in the body for particular instantiations |
| 16:02:06 | Demos | and so long as you put a type in procs using openarrays will generate code |
| 16:02:21 | Demos | or can, without there being any callsites |
| 16:06:14 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:06:43 | * | Ven joined #nim |
| 16:09:18 | * | yglukhov_ quit (Ping timeout: 246 seconds) |
| 16:14:56 | renesac | what having a size has to do if they are a real type or not? |
| 16:16:19 | * | HakanD_ quit (Quit: Be back later ...) |
| 16:16:55 | renesac | by the way, if I try to put an "| var string" on sort() I get type missmatch in the procs expecting the old sort |
| 16:17:11 | renesac | lib/packages/docutils/rstgen.nim(516, 6) Error: type mismatch: got (seq[TIndexEntry], proc (TIndexEntry, TIndexEntry): int{.gcsafe, locks: 0.} | proc (T, T): int | proc (string, string): int{.noSideEffect, gcsafe, locks: 0.}) |
| 16:17:11 | renesac | but expected one of: |
| 16:17:11 | renesac | algorithm.sort(a: var openarray[T] or string, cmp: proc (T, T): int{.closure.}, order: SortOrder) |
| 16:17:27 | renesac | is this a bug? |
| 16:23:55 | Araq | renesac: dunno. |
| 16:24:08 | Araq | how can it infer T when it's a string though? |
| 16:24:19 | renesac | oh |
| 16:24:33 | Araq | and do you really want to cmp single characters? |
| 16:24:43 | renesac | yep |
| 16:26:31 | renesac | anyway, I already gave up on algorithm.sort(0 |
| 16:26:41 | renesac | doing my own insertion sort is better |
| 16:26:42 | renesac | :P |
| 16:26:50 | renesac | and works |
| 16:29:49 | * | arnetheduck quit (Ping timeout: 264 seconds) |
| 16:30:16 | * | jholland joined #nim |
| 16:30:32 | * | rational joined #nim |
| 16:33:01 | * | BitPuffin joined #nim |
| 16:34:05 | Araq | IMHO we should simply export some templates that implement sorting. getting the type signature right for all possible combinations is too much effort |
| 16:34:34 | Araq | same for linked list handling |
| 16:34:51 | Araq | and "draw circle" |
| 16:43:17 | * | a5i quit (Quit: Connection closed for inactivity) |
| 16:43:41 | renesac | well, ideally we would have working concepts and sufficient compile time type introspection |
| 16:44:09 | * | pregressive joined #nim |
| 16:44:36 | renesac | so we can define sort(a : container, system.cmp[containedType(a))]) or something like that |
| 16:45:12 | renesac | maybe I'm too ambitious |
| 16:46:07 | renesac | by the way, is there some proc of the type "hasPointer()", to see if an object has some type of indirection |
| 16:46:17 | EXetoC | a temporary solution is fine |
| 16:47:03 | renesac | so that I could use it in a hash table, for example, to decide if I should store the hash alongside the value |
| 16:47:21 | renesac | it would return false for 'int' and true for 'string', for example |
| 16:47:32 | def- | renesac: maybe isOnStack |
| 16:48:56 | renesac | isOnStack receives a pointer |
| 16:49:04 | renesac | I can't give an "int" to it |
| 16:49:21 | renesac | I want to know if I have a pointer thingy in the first place |
| 16:51:23 | renesac | http://nim-build.nim-lang.org/system.html#isOnStack,pointer <-- I can't see the diference between the two isOnStack() |
| 16:51:37 | renesac | (look 4 procs down for the second one) |
| 16:51:38 | Araq | renesac: these should not be exported |
| 16:51:54 | renesac | and the 'see source' don't works for them |
| 16:52:06 | Araq | renesac: I'm well aware of "sort(a : container, system.cmp[containedType(a))]) or something like that" |
| 16:52:44 | Araq | and oh look, even that specifies it takes a 'cmp' proc pointer |
| 16:52:48 | renesac | well, they aparently are exported |
| 16:53:03 | Araq | which is not what I want for 'int' |
| 16:53:27 | renesac | why you don't want that for 'int'? |
| 16:53:37 | Araq | indirect calls are slow |
| 16:54:01 | renesac | I would imagine it being inlined by the compiler |
| 16:54:15 | Araq | don't count on it |
| 16:54:46 | Araq | and in general algorithms are stable, interfaces/signatures are not. |
| 16:54:46 | renesac | then the cmp for everything is slow |
| 16:55:11 | Araq | the cost can amortize when 'cmp' does quite some work |
| 16:56:24 | renesac | I would think that the more work larger would become the difference between inlined and not |
| 16:56:48 | renesac | as the overhead of the call sort itself is amortized |
| 16:56:53 | renesac | *sort call |
| 16:58:16 | Demos | C++ does it with a template argument, this gets inlined /sometimes/ |
| 16:58:31 | renesac | well, you could define a sort() proc that don't receive the comparison function |
| 16:58:37 | renesac | and simply uses > < = |
| 16:58:41 | renesac | inside |
| 16:58:54 | renesac | then it probably will get inlined? |
| 17:01:30 | Demos | and as you do more work in the cmp function you spend more time there, so the indirect call matters less |
| 17:02:07 | renesac | oh, right |
| 17:04:10 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:04:25 | Demos | As long as lambdas passed to cmp get inlined it is not a huge problem. In C++ the version with the cmp argument can be inlined when the target of the function can not change (true for inline lambdas and functors) |
| 17:06:25 | ggVGc | I'm a lambda, you're a lambda, and another little lambda, lambda lambda lambda lambda, lambda lambda, DUCK! |
| 17:06:32 | ggVGc | that's all I have to say for now |
| 17:07:37 | Demos | since a function pointer of a given type (like bool (*cmp)(int, int)) can point of any actual function you like these are unlikely to be inlined as compare functions |
| 17:08:33 | Demos | Essentially want I am saying is that the type of the cmp function passed to sort should be something like static[proc(T,T): bool] |
| 17:09:01 | renesac | right |
| 17:12:09 | * | Senketsu joined #nim |
| 17:14:51 | Demos | I can't wait until static works for everything |
| 17:14:54 | Demos | such a cool feature |
| 17:17:19 | renesac | yeah |
| 17:18:11 | * | Ven joined #nim |
| 17:30:54 | * | yglukhov_ joined #nim |
| 17:33:07 | * | wink-s quit (Ping timeout: 246 seconds) |
| 17:37:09 | * | MyMind quit (Ping timeout: 246 seconds) |
| 17:38:20 | Araq | Demos: well fortunately fixing static[T] fixes quite some other problems in the compiler as well :-) |
| 17:39:13 | * | gsingh93 joined #nim |
| 17:40:53 | * | irrequietus joined #nim |
| 17:43:25 | * | reem joined #nim |
| 17:45:58 | * | banisterfiend quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:52:47 | * | reem quit (Remote host closed the connection) |
| 18:00:20 | * | rational quit (Ping timeout: 252 seconds) |
| 18:02:03 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:02:36 | * | Strikecarl joined #nim |
| 18:02:47 | Strikecarl | Woopsie. |
| 18:02:50 | Strikecarl | Need help again <.< |
| 18:02:53 | Strikecarl | "invalid character constant" |
| 18:03:02 | Strikecarl | var source = "E:\keys.txt" |
| 18:04:09 | Araq | var source = r"E:\keys.txt" |
| 18:04:19 | vbtt_ | Strikecarl:backslash escapes |
| 18:04:23 | Strikecarl | Oh. |
| 18:04:26 | Strikecarl | Thanks! |
| 18:05:03 | vbtt_ | http://nim-lang.org/manual.html#string-literals |
| 18:05:12 | vbtt_ | double backslash should work too |
| 18:07:10 | * | gsingh93 quit (Ping timeout: 264 seconds) |
| 18:07:40 | Strikecarl | vbtt_ Thanks! |
| 18:07:56 | Araq | "although how it interferes with them, he still hasn't explained" omg no. I explained it 5000 times and the manual explains it too |
| 18:08:40 | Araq | but I don't care, I give up, let's kill .procvar. |
| 18:09:41 | vbtt_ | Araq: context? |
| 18:09:43 | Araq | still I wish I'd understand why people cannot understand .procvar |
| 18:10:07 | vbtt_ | nm, found the forum |
| 18:16:01 | vbtt_ | because nim reminds one of very high level languages (python etc.) - ppl might assume all procs are automatically first class objects |
| 18:17:02 | vbtt_ | will removing .procvar. mean that all procs are automatically procvars? |
| 18:19:39 | * | BlaXpirit quit (Remote host closed the connection) |
| 18:21:24 | * | BlaXpirit joined #nim |
| 18:25:43 | * | mwbrown joined #nim |
| 18:26:48 | def- | vbtt_: that would be the idea |
| 18:27:14 | renesac | Araq: where is the explanation? |
| 18:27:40 | renesac | I subscribed to that bug report waiting for your answer to Varriount... |
| 18:28:20 | Demos | ll I wish I'd understand why people cannot understand .procvar |
| 18:28:20 | Demos | 14:10 < vbtt_> nm, found the forum |
| 18:28:25 | Strikecarl | Does anyone know how to use --app:gui in Aporia without any compile errors? |
| 18:28:28 | renesac | I don't like the idea of being unable to add optional parameters to procs w/o breaking the interface |
| 18:29:17 | * | Strikecarl quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 18:29:45 | * | Strikecarl joined #nim |
| 18:30:21 | vbtt_ | Demos:my answer was to myself - regarding 'context?' |
| 18:30:59 | vbtt_ | I see the recent thread in the forum, not araq's explanation. http://forum.nim-lang.org/t/1099 |
| 18:31:00 | Demos | yeah, accedently copy pasted your message |
| 18:31:04 | Demos | because unix |
| 18:31:49 | Demos | I think it is because adding default parameters needs changes at the callsite |
| 18:33:10 | * | irrequietus quit () |
| 18:33:12 | Demos | Not sure how this could ever cause problems except for {.exportc.}'d procs |
| 18:33:57 | def- | Strikecarl: from what I've heard the mingw version nim ships on windows can't do --app:gui, you need a full one |
| 18:34:08 | vbtt_ | Demos: a recompile should fix the callsite, no/ |
| 18:34:12 | vbtt_ | no? |
| 18:34:16 | * | gsingh93 joined #nim |
| 18:34:30 | Demos | rihgt, but not with {.exportc.}. It would be an ABI change |
| 18:35:07 | vbtt_ | I see. I dont know much about compilation units in nim. |
| 18:35:25 | vbtt_ | I thought it takes *all* the source, even for all modules, and then compiles it down. |
| 18:35:26 | Demos | like if nim supported seperate compilation then it could cause a problem |
| 18:35:29 | Demos | and in theory it odes |
| 18:35:31 | Demos | *does |
| 18:36:26 | vbtt_ | How does {.procvar.} fix this? |
| 18:38:31 | Strikecarl | kk. |
| 18:38:32 | * | reem joined #nim |
| 18:38:34 | Strikecarl | Thanks def- |
| 18:39:47 | * | banister joined #nim |
| 18:41:48 | Strikecarl | def- i installed the newest version of MingW and replaced it with the one nim gave me |
| 18:41:57 | Strikecarl | if i dont use --app:gui it works fine |
| 18:42:01 | Strikecarl | but with app gui i get |
| 18:42:06 | Strikecarl | Error: execution of an external program failed |
| 18:42:19 | Strikecarl | am i missing something? $findExe(nimrod) c --app:gui $# |
| 18:44:55 | * | reem quit (Remote host closed the connection) |
| 18:47:12 | def- | you can try adding --parallelBuild:1 to see if it says sth more |
| 18:47:33 | def- | Maybe someone with Windows knows how to solve this |
| 18:49:03 | Strikecarl | Now it works :) |
| 18:49:04 | Strikecarl | Thanks! |
| 18:50:02 | * | pregressive quit (Remote host closed the connection) |
| 18:50:15 | Strikecarl | i think |
| 18:50:22 | Strikecarl | nope. |
| 18:50:27 | Strikecarl | Error: execution of an external program failed |
| 18:50:27 | Strikecarl | > Process terminated with exit code 1 |
| 18:51:59 | cazov | you could try using dependency walker to find out if its some missing dll |
| 18:52:22 | renesac | strange that compiling a Debug build in Nim is 3 times slower than a Release build |
| 18:52:34 | renesac | in C it is the opposite, because the optimizations |
| 18:54:48 | def- | renesac: for me debug builds are faster in nim |
| 18:55:48 | renesac | Hint: operation successful (21666 lines compiled; 1.018 sec total; 37.378MB; Debug Build) [SuccessX] |
| 18:55:48 | renesac | Hint: operation successful (21666 lines compiled; 0.290 sec total; 27.281MB; Release Build) [SuccessX] |
| 18:55:54 | renesac | the same program |
| 18:56:21 | def- | Maybe you didn't reset the nimcache |
| 18:56:59 | def- | or is it something special about your code? |
| 18:57:01 | renesac | ok, compiling again |
| 18:57:06 | renesac | Hint: operation successful (21666 lines compiled; 0.325 sec total; 37.378MB; Debug Build) [SuccessX] |
| 18:57:25 | renesac | and yeah, I'm not reseting the cache |
| 18:58:00 | def- | then do the debug build after not resetting the cache either? |
| 18:58:03 | renesac | Hint: operation successful (21666 lines compiled; 1.752 sec total; 27.281MB; Release Build) [SuccessX] <-- release with cold cache |
| 18:58:26 | renesac | so, the two are abou the same speed, but the release one is still a bit faster |
| 18:58:57 | * | Jehan_ joined #nim |
| 18:59:07 | renesac | when recompiling with the cache |
| 18:59:13 | renesac | but slower with cold cache |
| 18:59:26 | def- | i guess that makes sense |
| 18:59:40 | def- | with a debug build you generate much more C code than with release |
| 18:59:52 | Jehan_ | Debug builds generate additional code (such as linenumber and file information) and may import additional modules. |
| 18:59:58 | renesac | right |
| 19:00:28 | renesac | yeah, it was the nimcache effect that generated that big difference I initially was surprised |
| 19:00:29 | def- | but usually the C compiler's optimizations are the slowest part |
| 19:00:38 | * | Strikecarl quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 19:02:22 | renesac | and in debug mode the program runs slower than the python version, but in release mode it is 3 times faster than pypy |
| 19:02:54 | * | irrequietus joined #nim |
| 19:03:09 | renesac | of course because python has tons of optimized libraries that a non-optimized build can't touch |
| 19:03:26 | renesac | *can't compete |
| 19:06:54 | Jehan_ | You can selectively turn off a few things that you don't really need. |
| 19:07:10 | Jehan_ | Plus, you can turn on optimization in debug mode. |
| 19:07:24 | Jehan_ | This makes compilation slower, but the program runs faster. |
| 19:07:46 | Jehan_ | Personally, with clang, I pretty much always run with optimization on even in debug mode. |
| 19:08:26 | Jehan_ | Unless I have to debug with gdb (because then optimization may interfere with debugging). |
| 19:11:00 | * | rational joined #nim |
| 19:26:06 | * | Strikecarl joined #nim |
| 19:26:45 | Strikecarl | How do i read a REG_SZ value and make it to a string? |
| 19:51:37 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:52:52 | dtscode | Mimbus, echo $1 |
| 19:53:16 | EXetoC | .eval echo $1 |
| 19:53:17 | Mimbus | EXetoC: eval.nim(3, 5) Error: type mismatch: got (proc (varargs[expr]){.gcsafe, locks: 0.}, int literal(1)) |
| 19:55:28 | Strikecarl | How do i read a REG_SZ value and make it to a string? |
| 19:56:42 | * | polde quit (Ping timeout: 272 seconds) |
| 19:58:47 | * | Strikecarl quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 20:00:31 | * | polde joined #nim |
| 20:20:36 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 20:26:58 | * | gsingh93 quit (Ping timeout: 264 seconds) |
| 20:38:30 | * | polde quit (Ping timeout: 272 seconds) |
| 20:41:13 | * | polde joined #nim |
| 20:43:35 | * | mpthrapp quit (Remote host closed the connection) |
| 20:49:06 | Araq | renesac: thanks to .procvar taking the address of a proc usually doesn't work to begin with, so we can add default parameters to stdlib procs and not break anything. |
| 20:49:40 | Araq | that's the reason for its existance. |
| 20:50:34 | Araq | in a lang without procvar, we cannot add a default parameter and ensure we didn't break somebody's code. |
| 20:50:42 | renesac | [15:35:45] <Demos> like if nim supported seperate compilation then it could cause a problem |
| 20:50:42 | renesac | [15:35:48] <Demos> and in theory it odes |
| 20:50:43 | renesac | [15:36:45] <vbtt_> How does {.procvar.} fix this? |
| 20:51:04 | Araq | seperate compilation or ABIs etc have *nothing* to do with this. |
| 20:52:08 | Araq | also note that templates do not have an address you could take to begin with. .procvar actually make the whole language more consistent |
| 20:52:38 | renesac | what other languages with default arguments do? |
| 20:52:41 | Araq | and of course system.`+` is mapped to a CPU instruction, so again, you cannot take its address |
| 20:53:55 | Araq | what you can do is to *generate* stubs in these cases to strengthen the abstractions |
| 20:54:01 | renesac | semistatic[] for proc parameters would fix this? |
| 20:54:13 | renesac | *when receiving procs as parameters |
| 20:54:57 | Araq | I don't see how. |
| 20:55:22 | vbtt_ | consider the example in the forum:var lineNums = input.split(",").map(proc (x:string): string = x.strip()).map(proc (x:string): int = parseInt(x)) |
| 20:55:34 | vbtt_ | how does that not break when you add default parameters? |
| 20:55:45 | vbtt_ | so people will use workarounds, and be broken either way? |
| 20:56:14 | Araq | vbtt_: x.strip() is a call. not taking its address |
| 20:56:27 | Araq | so strip continues to work if we add more parameters |
| 20:56:44 | vbtt_ | ah I see |
| 20:57:28 | vbtt_ | maybe the solution is to just have a simple macro to auto-wrap these non-procvared functions? |
| 20:57:31 | Jehan_ | Except that things currently sort of breaks because of strip having default parameters (but that could be fixed). |
| 20:58:36 | vbtt_ | or just auto-wrap non-procvarred procs |
| 20:58:49 | Araq | that's what Jehan_ proposes, yes |
| 20:58:52 | vbtt_ | (that's how people expect it to work anyway) |
| 20:59:09 | Jehan_ | vbtt_: Basically, yeah, you can turn everything into a closure, can't turn everything into a procvar. |
| 20:59:51 | vbtt_ | right - well only if you use a proc like that it will create that closure? |
| 21:00:12 | renesac | what is the problem with Jehan_ proposal? |
| 21:00:24 | renesac | besides __effort__? |
| 21:00:27 | Jehan_ | I'm honestly not sure where procvars enter into the whole problem to begin with. The code doesn't compile for other reasons. |
| 21:00:44 | Araq | argh |
| 21:00:59 | Araq | nobody understands .procvar |
| 21:01:18 | Araq | Jehan_: parseInt is a good example. We promise .procvar for that |
| 21:01:45 | Araq | so I cannot modify it to proc parseInt(s: string; start = 0): int |
| 21:01:52 | Araq | as that would break code |
| 21:02:11 | Araq | but without the .procvar I *could* do that |
| 21:02:24 | Araq | as you cannot take its address then |
| 21:02:31 | Jehan_ | Araq: Yeah, but you can also make a proc a {.closure.} and it would work with map. |
| 21:02:33 | vbtt_ | Ah |
| 21:02:42 | vbtt_ | so procvar says 'this proc signature cannot be modified' ? |
| 21:02:55 | Jehan_ | map's argument has to be a closure, can turn a procvar into a closure, but not vice versa. |
| 21:03:01 | vbtt_ | it should be called 'frozen-api' or something |
| 21:03:03 | Araq | yes. it's a promise |
| 21:04:17 | renesac | so, why a frozen proc signature is needed for map()? |
| 21:04:18 | Araq | Jehan_: toplevel .closures are a mistake and we need to kill them. ;-) |
| 21:04:33 | Jehan_ | *blink* |
| 21:04:39 | * | renesac is still lost at a more basic level |
| 21:05:13 | renesac | and what other languages with default arguments do? |
| 21:05:44 | * | polde quit (Ping timeout: 272 seconds) |
| 21:05:44 | Jehan_ | renesac: In other languages with higher-order functions, everything is a closure (sort of). |
| 21:06:14 | vbtt_ | well... |
| 21:08:59 | renesac | so in D everything is a closure? |
| 21:09:14 | renesac | it supports default values, and things like map() |
| 21:09:49 | Jehan_ | No, D has both delegates (= closures) and function pointers. |
| 21:09:59 | renesac | I don't remember ithaving some {.procvar.} problem |
| 21:10:17 | renesac | how is that different from nim? |
| 21:10:54 | * | polde joined #nim |
| 21:11:43 | vbtt_ | What I don't get is why promising unchanging signature is important. Nim will always recompile with all the source code, so it will always pick up the latest version of the function, no? |
| 21:13:02 | BlaXpirit | vbtt_, think about serious real world stuff |
| 21:13:06 | Jehan_ | renesac: You don't have a procvar problem in Nim, either. At least what we've been discussing on the forum has nothing to do with strip not being a procvar. The code doesn't compile because there's a type mismatch because of optional parameters, but that type mismatch occurs regardless of whether strip is a procvar or closure. |
| 21:13:22 | BlaXpirit | like, programs compiled, maybe in linux distros |
| 21:13:28 | BlaXpirit | libraries made in nim |
| 21:13:34 | BlaXpirit | gotta keep binary compatibility and stuff |
| 21:13:47 | vbtt_ | BlaXpirit:right, I understand the use of procvar for binary compatibility |
| 21:13:59 | vbtt_ | (not sure I buy it, but I get the point) |
| 21:14:30 | flaviu | Does Nim even allow dynamically linking nim libraries? |
| 21:14:43 | Araq | flaviu: yes it does. |
| 21:14:44 | vbtt_ | however, Araq said it has nothing to with ABI or separate compilation |
| 21:14:52 | Araq | but this all besides the point |
| 21:15:11 | renesac | Jehan_: are you sure you didn't solve the problem simply because you declared the mystrip() in your compilation unit? |
| 21:15:17 | flaviu | Araq: Without having to go through bunch of trouble with exportc? |
| 21:15:51 | Araq | flaviu: the stdlib uses the .rtl pragma for it |
| 21:15:57 | Jehan_ | renesac: Sort of, yeah. |
| 21:16:32 | Araq | vbtt_: so you write program A against the stdlib. |
| 21:16:45 | Araq | we update the stdlib and add a default param to proc foo which you use. |
| 21:16:59 | renesac | Assigning/passing a procedure to a procedural variable is only allowed if one of the following conditions hold: |
| 21:16:59 | Araq | with .procvar we don't have to announce this as a breaking change. |
| 21:16:59 | renesac | The procedure that is accessed resides in the current module. |
| 21:16:59 | renesac | The procedure is marked with the procvar pragma (see procvar pragma). |
| 21:16:59 | renesac | The procedure has a calling convention that differs from nimcall. |
| 21:16:59 | renesac | The procedure is anonymous. |
| 21:17:11 | Araq | I mean with .procvar *in the language* |
| 21:17:20 | * | banister joined #nim |
| 21:17:37 | renesac | Jehan_: you automatically filled the first condition declaring mystrip() |
| 21:17:43 | Araq | without .procvar in the language it IS a breaking change. |
| 21:18:03 | Araq | unless we do some gymnastics and generate closures under the hood for you. |
| 21:18:11 | Araq | which we don't. |
| 21:18:51 | Araq | no ABIs, no DLLs no nothing involved in this problem. |
| 21:19:39 | vbtt_ | Araq: so - all procvar does it auto-generate the closure for me? |
| 21:19:46 | Araq | no,no,no |
| 21:20:04 | vbtt_ | if you add a default parameter to foo, which I use, it's a breaking change |
| 21:20:06 | Araq | procvar is a promise we won't add default params and so taking its address is allowed |
| 21:20:12 | vbtt_ | ah |
| 21:20:24 | vbtt_ | so basically, you can't add default params to procvar procs |
| 21:20:30 | Araq | exactly |
| 21:20:31 | vbtt_ | meh |
| 21:20:33 | renesac | why is it bad to take the address if the parameters change? |
| 21:20:45 | renesac | a list of reasons |
| 21:20:55 | Araq | renesac: because it's not a compatible type then anymore |
| 21:21:41 | renesac | can't the compatibility check see that those are optional parameters? |
| 21:21:48 | renesac | give an example why it breaks |
| 21:21:55 | renesac | I think it would make things clear for me |
| 21:22:10 | Araq | var foo: proc (s: string) = parseInt |
| 21:22:21 | Araq | --> stdlib's parseInt grows a param |
| 21:22:31 | vbtt_ | Araq:how does it matter if it's a 'breaking change' or not. are you saying I dont need to recompile when you update the stdlib? |
| 21:22:35 | Araq | --> your code with 'foo' doesn't compile anymore |
| 21:23:14 | Araq | vbtt_: you have to recompile but you cannot recompile because it breaks your code ffs |
| 21:23:14 | vbtt_ | So I'll recompile, see the error and fix my code. |
| 21:23:41 | vbtt_ | I mean, unless I use only procvar procs, I'm going to have to fix my code for such changes anyway |
| 21:23:56 | Araq | no, you don't. |
| 21:24:23 | Araq | because you were forced to write proc () = cannotTakeAddrFromthis(a, b) to begin with! |
| 21:24:36 | Demos | to be honest procvar is nice for other reasons, you get to specifically say what parts of your library need ABI compat (yes I understand ABI is not the reason for the stdlib) |
| 21:25:10 | Jehan_ | renesac: What I was getting at that you can declare things as {.closure.} and then they work, too. Except that for some reason Araq doesn't seem to like them. :) |
| 21:25:46 | Araq | Jehan_: toplevel .closure *barely* works and caused a combinatorial explosion in the codegen to deal with |
| 21:25:59 | Jehan_ | Araq: Gotcha. |
| 21:26:38 | reactormonk | I'd say the correct way to handle parsing stuff would be a sum return type - I mean we already have case objects |
| 21:26:47 | vbtt_ | Araq: sorry still dont get it but i'll think about it. what i don't get is why is taking an address different from a call. does the type of the function not travel with the address? |
| 21:27:15 | Araq | taking an address is *very* different. |
| 21:27:28 | Araq | for a start, the address has to exist. ;-) |
| 21:27:38 | vbtt_ | right, i get that about '+' |
| 21:27:46 | Araq | templates have no address as these are compile-time only things |
| 21:28:17 | reactormonk | Araq, the address always exists, but you can't guarantee it? |
| 21:28:58 | vbtt_ | I can accept that I can't pass around a template as a first class object during runtime. |
| 21:29:13 | * | mwbrown quit (Ping timeout: 264 seconds) |
| 21:29:40 | vbtt_ | but procs are available at runtime. most have addresses, no? |
| 21:29:54 | Araq | ok, so what if we like to transform proc foo to template foo in the stdlib? (doesn't happen very often but still) |
| 21:30:02 | renesac | well, the missing link is understanding how a call is made from a function pointer |
| 21:30:12 | renesac | nim uses fastcall |
| 21:30:16 | vbtt_ | right that's the breaking change. |
| 21:30:18 | Araq | again with .procvar in the language, not a breaking change |
| 21:30:33 | vbtt_ | well, with prorvar in the language, not possible |
| 21:30:33 | Araq | without .procvar in the language, it becomes a breaking change |
| 21:30:44 | vbtt_ | well is it even possible with procvar? |
| 21:30:52 | renesac | if you call the proc expecting a smaller number of arguments |
| 21:30:57 | renesac | it won't clear all the registers? |
| 21:31:17 | flaviu | Isn't it possible just to disallow taking the address of a proc? |
| 21:31:23 | renesac | or it will give an error accessing things that should have been on the call stack? |
| 21:31:32 | Araq | flaviu: that's what we do. |
| 21:31:39 | Araq | well I give up. |
| 21:31:50 | renesac | lol |
| 21:31:59 | Araq | I still don't get why .procvar is so hard to understand |
| 21:32:00 | vbtt_ | wait |
| 21:32:04 | vbtt_ | i think i get it |
| 21:32:25 | renesac | well, at least I understand what procvar does |
| 21:32:28 | vbtt_ | basically procvar says "we are not going to change this proc in ways which make taking an address impossible, so you can take the address of this proc" |
| 21:32:40 | Araq | YES! |
| 21:32:43 | renesac | what I still don't fully understand is why it is needed, and possible alternatives to it |
| 21:33:48 | flaviu | Another option might be to generate a new proc each time someone asks for the address of the proc. |
| 21:33:56 | Demos | it is breaking w/o procvar in that someone may be calling the function vai a pointer |
| 21:33:59 | vbtt_ | well you made a static, systems language that looks like a high level language, of course people are confused when not everything is addressable ;-) |
| 21:34:45 | renesac | yeah, and what happens when you call a function via a pointer using less arguments than it takes? |
| 21:34:57 | renesac | at the low level? |
| 21:34:57 | Demos | or may be trying to take a pointer and you want to make the function generic |
| 21:35:05 | Demos | renesac: you don |
| 21:35:08 | Demos | don't do that |
| 21:35:21 | Araq | renesac: the type system prevents this |
| 21:35:25 | Demos | like in C this happens if you screw up calls to vararg functions |
| 21:35:25 | Araq | but when you 'cast' around it |
| 21:35:40 | Araq | it often works ;-) |
| 21:35:43 | renesac | yeah, that is what I'm thinking |
| 21:35:45 | Araq | and often it doesn't |
| 21:35:47 | Demos | it is bad |
| 21:35:56 | Demos | and when it does not anything can happen |
| 21:35:59 | renesac | what makes it not work? |
| 21:36:06 | renesac | just wanted to understand that |
| 21:36:25 | Demos | so when you call a function you have to push args onto the stack |
| 21:36:40 | vbtt_ | Araq:in any case, auto-generating closures for wrapping non-procvar procs is probably a very useful feature. |
| 21:36:44 | Demos | if you were to push too few than the callee would pop off the stack an extra time |
| 21:36:47 | vbtt_ | because it meets expectations. |
| 21:36:54 | Araq | yes, I agree |
| 21:37:06 | renesac | ok, it is what I suspected |
| 21:37:24 | Demos | vbtt_: I am not so sure, I don't really expect a closure when I take an address |
| 21:37:33 | renesac | so what does D do to make this transparent? |
| 21:37:43 | renesac | it creates a closure for you when calling map()? |
| 21:37:58 | Araq | renesac: I think adding a default param is simply a breaking change in D. |
| 21:38:06 | renesac | hum |
| 21:38:29 | Araq | that's what the other languages do. they don't care about the hole :P |
| 21:39:55 | vbtt_ | I get why chaning proc to a template prevents taking the address. But why does adding a default param prevent taking the address? |
| 21:40:09 | vbtt_ | I mean, it's still a proc with an address |
| 21:40:13 | Demos | right |
| 21:40:24 | Demos | but you need to do something like the following to call |
| 21:40:35 | Demos | save registers |
| 21:40:38 | Demos | push p1 |
| 21:40:40 | Demos | push p2 |
| 21:40:44 | Demos | push newparam |
| 21:40:47 | Demos | call addr |
| 21:40:54 | vbtt_ | Demos:nim compiles to C, so yo udont do all that. |
| 21:41:11 | Demos | right, but the c compiler totally does |
| 21:41:21 | vbtt_ | yes. |
| 21:41:27 | Demos | oh |
| 21:41:28 | Demos | right |
| 21:41:34 | Demos | in addition |
| 21:41:51 | Demos | the type changes, so if you write out var f: proc(int,int) = somefunc |
| 21:41:56 | Demos | and somebody adds a default param |
| 21:42:01 | Demos | the code does not compile |
| 21:42:19 | Demos | the /reason/ the type changes is because of how the stack works |
| 21:42:51 | vbtt_ | understood |
| 21:43:09 | qwr | hm, can't you work around it using overloading? |
| 21:43:09 | Araq | no, that's not the reason. the reason is type safety. |
| 21:44:09 | Araq | a type system usually doesn't reflect low level implementation details |
| 21:44:48 | * | ggVGc is now known as walt |
| 21:47:07 | qwr | imho you could default params simply by generating overloading function without the param that calls the one with the param, giving the correct value |
| 21:47:26 | Araq | qwr: yes that works, but causes some code bloat |
| 21:47:47 | Araq | in fact, it causes a combinatorial explosion |
| 21:48:01 | qwr | yes, with multiple default arguments |
| 21:48:09 | vbtt_ | java people do this by hand :) |
| 21:48:25 | flaviu | Araq: It's much cheaper if done on-demand. |
| 21:48:41 | Araq | flaviu: we discussed this. |
| 21:49:01 | Araq | it's possible and only Demos doesn't like it, but we don't have it. |
| 21:49:53 | renesac | there is some measurement on how much bloat it would generates on average? |
| 21:50:02 | renesac | or because it is impossible there is no such code to test? |
| 21:50:13 | renesac | *it is currently impossible |
| 21:51:29 | renesac | and most of the time the function pointer is statically known |
| 21:51:42 | renesac | the name of the proc is passed directly at the map() call site |
| 21:52:26 | Araq | renesac: procs with lots of default parameters are not that uncommon |
| 21:52:31 | renesac | the compiler could then adapt it to call the proper function with default parameters |
| 21:52:42 | Araq | we don't have to measure it, it's bad :P |
| 21:53:05 | qwr | you can calculate how bad it is, no need to measure |
| 21:53:08 | renesac | Araq: yes, but if done on demand you will only need one more version of it most of the time |
| 21:53:19 | renesac | and the original version might not even be needed |
| 21:53:29 | renesac | like in the case of split() in that program from the forum |
| 21:53:35 | Araq | renesac: we already agreed the on demand solution is nice. |
| 21:53:39 | renesac | only a split(s:string) is needed |
| 21:53:56 | renesac | I though Demos didn't |
| 21:54:52 | Araq | well ok, not everybody agreed. |
| 21:54:59 | Araq | big deal :P |
| 21:56:37 | renesac | his rejection is on phylosophical grounds or that he is afraid of the average bloat? |
| 21:57:11 | renesac | but yeah, in a langauge like nim with templates, static[], etc, this solution is the most fitting IMHO |
| 21:57:30 | Araq | he's simply smart enough not to expect the programming language solving every single problem for him :P |
| 21:58:13 | renesac | ok, so it was anti-feature-creep, or a desire to keep what nim does behind the scenes understandable (like C)? |
| 21:59:08 | renesac | I like things working seamless, but also to know how and when magic occurs |
| 22:01:23 | Araq | the desire here was "ugh, no way, we have other things to do" |
| 22:01:53 | Araq | usually features start in the "not implemented" state. |
| 22:02:04 | renesac | ok, so put it on TODO and point people to it from now on |
| 22:02:31 | renesac | :) |
| 22:02:58 | Sembei | we have release dates for nim 1.0 ? |
| 22:03:26 | renesac | I don't really care when that is done, I agree that there are more important things |
| 22:04:58 | renesac | like foward declarations, people are a little annoyed to discover Nim requires that, but "we havent gone around doing it yet, but we will do it" prevents undue anger |
| 22:05:00 | renesac | ;) |
| 22:05:25 | Araq | Sembei: we had december 2014. then we had march 2015. |
| 22:05:46 | Araq | we haven't even managed to release 0.10.4 |
| 22:06:12 | renesac | originally, there wouldn't be 0.10.x at all |
| 22:06:13 | Sembei | not even a pre alpha? |
| 22:06:38 | Araq | "pre alpha" is meaningless to me |
| 22:06:38 | renesac | Sembei: the universal answer works here: when it is done |
| 22:06:50 | renesac | Sembei: you can have your pre-alpha |
| 22:06:56 | renesac | just compile from github devel HEAD |
| 22:07:06 | Sembei | I know |
| 22:07:21 | Araq | it's hardly pre-alpha when people use it in production |
| 22:08:03 | Sembei | at some point should be beta then |
| 22:08:36 | flaviu | Or maybe those people are just masochists |
| 22:08:52 | * | saml quit (Quit: Leaving) |
| 22:14:08 | * | polde quit (Ping timeout: 272 seconds) |
| 22:14:33 | * | renesac quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 22:14:47 | Araq | Sembei: we wil have "release candidates" before 1.0 |
| 22:14:59 | * | renesac joined #nim |
| 22:15:18 | * | polde joined #nim |
| 22:15:35 | Araq | we could call the first release candidate "beta" I guess? |
| 22:15:37 | Demos | I mostly had a problem with generateing closures on the fly |
| 22:16:17 | Demos | which is what java does now that I think about it |
| 22:17:25 | * | wan quit (Ping timeout: 248 seconds) |
| 22:17:45 | Demos | also, it is rare to have functions that you want to take the address of without knowing you will beforehand |
| 22:17:56 | EXetoC | < 2016? :p |
| 22:18:26 | renesac | Demos: but it isn't rare to use stdlib procs in functional programming |
| 22:19:10 | renesac | for people who like the style |
| 22:19:58 | Araq | renesac: exactly. FP makes this problem quite severe these days |
| 22:23:27 | federico3 | are there non-homogeneous arrays? |
| 22:24:37 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 22:24:52 | renesac | federico3: for what you need them? |
| 22:24:56 | Araq | federico3: the Json module provides such a thing as a side-effect? |
| 22:25:19 | federico3 | just trying to learn - I'm so confused by the whole language |
| 22:25:32 | renesac | nim is a typed language, it is a bit difficult to work with non-homogeneous arrays |
| 22:25:49 | renesac | federico3: are you comming from python? |
| 22:25:53 | federico3 | yep |
| 22:26:09 | renesac | any experience in a typed/staticaly compiled language? |
| 22:27:28 | federico3 | not much. I was trying creating: seq[ParentObjectType] = @[] |
| 22:27:43 | federico3 | and then adding two objects inheriting from ParentObjectType |
| 22:27:48 | def- | federico3: oh, that works |
| 22:27:57 | federico3 | it doesn't here :) |
| 22:27:57 | def- | federico3: but make sure you are inheriting with refs |
| 22:28:02 | federico3 | aha! |
| 22:28:19 | renesac | yeah, otherwise the object sizes are different |
| 22:28:28 | def- | otherwise even "var x: ParentObjectType = someChild" will cut off parts of the object |
| 22:28:33 | renesac | but a ref to that object is constant size |
| 22:28:53 | renesac | python always works with refs |
| 22:29:47 | federico3 | is there a best practice of always using refs in Nim [unless there are very specific performance reasons]? |
| 22:30:27 | Araq | I guess you can say that, yes. esp for people coming from python. |
| 22:30:40 | vbtt_ | agree - if you're from python, start with using refs |
| 22:30:46 | walt | ^ slightly condescending :) |
| 22:31:07 | reactormonk | although value types have their advantages are certain points |
| 22:31:09 | vbtt_ | why? it matches what python does |
| 22:31:27 | * | wan joined #nim |
| 22:31:39 | federico3 | I've been using C, I'll have to get used to think ptrs/refs again |
| 22:32:06 | vbtt_ | well if you're comfortable with c then not using refs is fine too ;-) |
| 22:32:39 | * | Kingsquee joined #nim |
| 22:32:43 | vbtt_ | you can't create an array of disparate structs in c |
| 22:32:54 | renesac | https://github.com/Araq/Nim/wiki/Nim-for-C-programmers <-- We need a "Nim for Python programmers" |
| 22:33:04 | flaviu | federico3: Inheritance -> always use ref. Small simple data object -> don't use ref. |
| 22:33:05 | federico3 | yes! |
| 22:33:13 | reactormonk | renesac, go team up with federico3 and write one |
| 22:33:15 | federico3 | thanks flaviu ! |
| 22:33:27 | federico3 | thank you guys! |
| 22:33:46 | renesac | I personally like generic programming instead of inheritance |
| 22:34:06 | reactormonk | what's the difference betwen method and multi-methods? |
| 22:34:27 | reactormonk | renesac, yup, inheritance in nim tends to be annoying. |
| 22:35:35 | vbtt_ | reactormonk: they're the same in nim, I believe |
| 22:36:21 | vbtt_ | reactormonk:In general methods only dispatch based on the target object, aka the first parameter. but mulit-methods dispatch based on one or more arguments. |
| 22:36:31 | reactormonk | vbtt_, kk |
| 22:42:59 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 22:44:00 | vbtt_ | z[5] = 5 # Error: Cannot assign to z < - in Nim-for-C-programmers - confusing line - should not be both out-of-bounds and non-var |
| 22:58:36 | def- | vbtt_: it's a wiki, you can fix it |
| 22:58:44 | renesac | https://github.com/Araq/Nim/wiki/Nim-for-Python-Programmers <-- here a first draft |
| 22:59:06 | renesac | federico3: help out writting the code snippets on what you did |
| 22:59:23 | federico3 | oopsie |
| 22:59:40 | renesac | ? |
| 22:59:41 | federico3 | I was saving the same page right now! |
| 22:59:46 | renesac | oh |
| 22:59:51 | reactormonk | renesac, neat |
| 23:00:11 | renesac | sorry, I should have warned that I started doing it |
| 23:00:18 | federico3 | same here |
| 23:00:30 | renesac | yeap :P |
| 23:00:47 | federico3 | renesac: I just pasted some chunks from the page about C |
| 23:01:04 | pigmej | hmm |
| 23:01:23 | pigmej | why I can't get addr of my object ? |
| 23:01:27 | federico3 | the cheat sheet is unmanageable unless you have some better editor |
| 23:01:35 | pigmej | "Expression has no address" |
| 23:01:36 | def- | pigmej: it has to be a var |
| 23:01:52 | pigmej | def-: I can't get addr of proc argument? |
| 23:02:01 | def- | pigmej: right |
| 23:02:06 | pigmej | hmm |
| 23:02:28 | pigmej | but assigning to var makes copy, right? |
| 23:02:56 | federico3 | renesac: I'll just remove the cheat sheet, ok? |
| 23:03:07 | renesac | federico3: yeah, it is better |
| 23:03:44 | renesac | I don't think one needs to warn about unsigned on this page |
| 23:03:53 | renesac | as python don't have anything like that |
| 23:04:47 | * | irrequietus quit () |
| 23:04:57 | def- | pigmej: right |
| 23:05:03 | federico3 | saved. Yep, but rather a notice: your ints are going to be ints, not infinite size |
| 23:05:11 | renesac | yeah |
| 23:05:32 | pigmej | def-: hmm, how can I avoid that ? pass ref already to proc? |
| 23:05:42 | def- | pigmej: what do you need the address for? |
| 23:06:08 | pigmej | curently I'm playing with nim, so probably nothing serious |
| 23:06:16 | def- | pigmej: also see this forum thread: http://forum.nim-lang.org/t/851 |
| 23:06:16 | pigmej | but I wanted to have addr to write it to a file :) |
| 23:06:41 | def- | especially the explanations by Jehan |
| 23:06:41 | pigmej | (I know it's not portable etc) but it's mmap file so let's say I don't care about potability / os things etc |
| 23:06:42 | renesac | maybe "bigints: Yes (transparently) - Yes (via nimble package)" |
| 23:06:55 | Jehan_ | proc foo(x: int) = var x = x; do_something_with(addr(x)) |
| 23:06:59 | renesac | I will edit it |
| 23:07:35 | * | jefus__ joined #nim |
| 23:07:35 | dom96 | Araq: The docs tell you how to do it. |
| 23:07:48 | pigmej | Jehan_: yeah I just wanted to avoid that copy ;-) |
| 23:08:10 | federico3 | (stupid wiki with no locking mechanism) |
| 23:08:45 | renesac | oh |
| 23:08:47 | def- | federico3: the wiki is a git repo, you can use it as that |
| 23:08:51 | renesac | then I wont edit |
| 23:08:53 | * | Trustable quit (Remote host closed the connection) |
| 23:08:54 | def- | federico3: then you can merge and stuff |
| 23:09:01 | Jehan_ | pigmej: The compiler will optimize it out if possible. |
| 23:09:12 | renesac | better |
| 23:09:29 | renesac | commit your changes, tell it here, then I do mine |
| 23:09:37 | federico3 | def-: afaik you can fetch it from git, but maybe merging it requires sending a PR to Araq? |
| 23:09:49 | federico3 | renesac: go on go on |
| 23:10:04 | pigmej | Jehan_: hm, but isn't it awkward ? I have an obj, it's still living obj, why I can't get addr to dump it? |
| 23:10:12 | pigmej | I mean, it's awkward for me as nim n00b |
| 23:10:46 | def- | federico3: pretty sure you can push directly |
| 23:10:51 | Jehan_ | pigmej: The argument may not even have an address, say, because it lives in a register. |
| 23:10:52 | * | jefus_ quit (Ping timeout: 250 seconds) |
| 23:11:00 | federico3 | def-: thanks |
| 23:11:07 | Jehan_ | What gcc does when you do &a is to actually create a copy on the stack. |
| 23:11:17 | renesac | done |
| 23:11:19 | Jehan_ | Assuming a is an argument. |
| 23:11:48 | Jehan_ | Which makes the compiler more complicated without providing any actual benefit. |
| 23:12:45 | reactormonk | federico3, might be some branch of the main repo |
| 23:12:49 | pigmej | Jehan_: hmm, ok, I quite understand it then ;) |
| 23:12:53 | flaviu | pigmej: You want to write the proc address to a file? I think that'll be unusable between program invocations. |
| 23:13:08 | pigmej | flaviu: not proc address |
| 23:13:18 | reactormonk | renesac, mind if I slap it on https://github.com/Araq/Nim/wiki ? |
| 23:13:23 | pigmej | an address of proc argument (which is object in fact there) |
| 23:13:43 | reactormonk | pigmej, that sounds terrible. What are you trying to do? |
| 23:13:54 | flaviu | But the lifetime of that address expires when the proc returns. |
| 23:14:10 | pigmej | flaviu: and fine ;-) I just need to store it :D |
| 23:14:10 | renesac | reactormonk: ok, but it is still in a pretty bad shape |
| 23:14:39 | pigmej | reactormonk: I have some python (sic!) code which uses struct to save objects and hmm |
| 23:14:50 | pigmej | it lack performance, I'm trying to experiment with nim |
| 23:14:50 | renesac | the wiki needs to be more organized, with a proper hierarchy and more wiki links |
| 23:14:57 | reactormonk | renesac, ok, you do it when you choose to then ;-) |
| 23:15:14 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:15:23 | reactormonk | pigmej, so you're serializing stuff? |
| 23:15:28 | pigmej | reactormonk: yeah |
| 23:15:29 | renesac | the "pages" box on the right is starting to be really inadequate |
| 23:15:31 | pigmej | but fixed size needed |
| 23:15:35 | renesac | with "show 10 more pages" |
| 23:15:41 | pigmej | with as small overhead as possibl |
| 23:15:44 | pigmej | possible* |
| 23:15:55 | pigmej | the data is very very structured. |
| 23:16:12 | reactormonk | pigmej, so you have a serialization format given? |
| 23:16:31 | pigmej | reactormonk: no, I just know what comes in |
| 23:16:43 | pigmej | I wrap it with obj then I wanted to store it in file |
| 23:16:52 | pigmej | mmap file if that matters |
| 23:17:04 | pigmej | and later, obviously read it back ;-) |
| 23:17:08 | pigmej | the problem => fixed size need |
| 23:17:10 | pigmej | needed* |
| 23:17:16 | renesac | reactormonk: bah, I think it is better now than forgetting about adding it |
| 23:17:25 | reactormonk | no C libraries out there that do what you want? |
| 23:17:27 | renesac | I'm adding it |
| 23:17:30 | reactormonk | kk |
| 23:17:49 | pigmej | reactormonk: I have no idea ;-) |
| 23:18:13 | vbtt_ | pigmej:where do you get this data from? |
| 23:18:19 | pigmej | network ;-) |
| 23:18:28 | pigmej | nanomsg in fact but it doesn't matter at all |
| 23:18:34 | pigmej | (I think) |
| 23:18:38 | vbtt_ | pigmej:so why not just dump the byte array directly into mmap or file? |
| 23:18:43 | vbtt_ | you dont' need the address |
| 23:19:39 | pigmej | vbtt_: data processing is obviously needed ) |
| 23:19:40 | pigmej | ;-) |
| 23:20:04 | pigmej | data comes to me via nanomsg with msgpack / protobuf format |
| 23:21:11 | pigmej | in fact I thought that's the easiest way :) if there is other way then awesome, but what is it ;D |
| 23:21:38 | vbtt_ | pigmej: not sure how getting the address to an object helps you. |
| 23:21:55 | pigmej | writeBuffer(f, obj.addr, obj.sizeof) |
| 23:22:07 | vbtt_ | bah |
| 23:22:16 | vbtt_ | what is this, C? ;-) |
| 23:22:26 | vbtt_ | don't you already have a byte array? |
| 23:22:36 | vbtt_ | (not sure what type of object you have) |
| 23:22:42 | Araq | pigmej: you can pass 'obj' via 'var' and then its address is available |
| 23:24:14 | pigmej | Araq: yeah I know this already ( Jehan_ + def- mentioned that) |
| 23:24:29 | pigmej | I just wondered why, then Jehan_ quite explained :) |
| 23:24:44 | Araq | ok |
| 23:25:57 | renesac | https://rolandwarmerdam.co.nz/github-wiki-sidebars/ <-- it seems one can have quite a bit of fun with github wiki |
| 23:26:33 | renesac | I was just looking to ways of hiding some entries, like the GSOC ones from the sidebar |
| 23:26:44 | renesac | leaving a manageable number of quick links there |
| 23:28:21 | pigmej | but it's still awkward to me ;) |
| 23:30:08 | pigmej | but also what's more important, Nim is really cool :) |
| 23:30:49 | * | yglukhov_ quit (Quit: Be back later ...) |
| 23:31:51 | renesac | https://github.com/Netflix/Hystrix/wiki <-- something like this sidebar style |
| 23:31:54 | * | yglukhov_ joined #nim |
| 23:32:03 | renesac | the Pages is hidden by default, and there is a table of contents instead |
| 23:32:40 | renesac | https://github.com/Netflix/Lipstick/wiki <-- better yet |
| 23:33:36 | renesac | ugh, git clone failed |
| 23:33:37 | pigmej | renesac: wiki/_Sidebar/_edit |
| 23:33:39 | flaviu | https://help.github.com/articles/creating-a-sidebar/ |
| 23:33:45 | * | Jehan_ quit (Quit: Leaving) |
| 23:34:29 | pigmej | afair there was also a way with Sidebar.md |
| 23:34:36 | renesac | ok, someone with admin status must do it, aparently |
| 23:34:36 | pigmej | or something ;-) |
| 23:34:45 | renesac | at least from the graphical interface |
| 23:35:39 | pigmej | renesac: add _Sidebar.md in folders |
| 23:36:02 | federico3 | bye o/ |
| 23:36:11 | * | yglukhov_ quit (Ping timeout: 250 seconds) |
| 23:36:12 | pigmej | https://github.com/gollum/gollum/blob/6fc3b4be75211957ee11725ff690e74d51bec1b2/test/test_app.rb#L594 |
| 23:37:32 | renesac | I never touched that |
| 23:52:02 | * | vbtt_ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |