| 00:00:07 | dom96 | and then people say 'yes' when they mean that they don't mind? |
| 00:00:11 | BitPuffin | or when people say "as the question" :) |
| 00:00:19 | OrionPK | well. fuck. |
| 00:00:19 | Varriount | dom96: Yes. |
| 00:00:27 | dom96 | OrionPK: I know right. |
| 00:00:29 | Varriount | The emotional connotation supplied with the answer is far more important than the answer itself, in that case. |
| 00:00:35 | OrionPK | :-\ |
| 00:00:36 | EXetoC | either he could care a lot less, or just a little less. one of those |
| 00:00:58 | Varriount | EXetoC: I he could care not at all. |
| 00:01:02 | Varriount | *Or |
| 00:01:08 | dom96 | https://www.youtube.com/watch?v=om7O0MFkmpw |
| 00:01:55 | BitPuffin | Varriount: well you can't care less than not at all |
| 00:02:04 | BitPuffin | so saying so makes a person look douchey |
| 00:02:55 | EXetoC | maybe you can 'not care' a negative amount |
| 00:03:12 | EXetoC | I guess it wraps around then |
| 00:03:42 | BitPuffin | I ain't not got no money |
| 00:04:49 | dom96 | That video has graphs and shit. |
| 00:04:57 | dom96 | It explains it pretty well. |
| 00:08:46 | Varriount | dom96: Regarding watching a directory for changes to itself on windows, I'm just gonna make it so that a directory can be watched like a file for now. |
| 00:09:52 | dom96 | Varriount: I think it may be best for you to just implement as you think is best. Once I can test it, it will be easier for me to determine what I dislike :P |
| 00:16:52 | * | saml_ joined #nimrod |
| 00:17:40 | * | flaviu joined #nimrod |
| 00:18:40 | * | superfunc quit (Quit: leaving) |
| 00:19:12 | flaviu | 12% faster |
| 00:19:57 | flaviu | did a message get dropped? |
| 00:20:05 | flaviu | "BitPuffin: FYI, my new is actually faster with the memcpy than standard PThing()" |
| 00:21:25 | Araq | it's 12% faster but it's also wrong |
| 00:21:45 | Varriount | *gasp!* |
| 00:22:08 | flaviu | I was thinking something like that, I'm not really sure how this interacts with everything |
| 00:22:40 | NimBot | nimrod-code/babel master a541387 Dominik Picheta [+0 ±1 -0]: Normalise cmd line pkg name and ver range parsing. |
| 00:22:40 | NimBot | nimrod-code/babel master 0d6dabb Dominik Picheta [+0 ±1 -0]: Added docs for uninstall command to readme. |
| 00:23:56 | flaviu | Araq: Can you elaborate on how its wrong? |
| 00:24:56 | Araq | GC'ed fields need the write barrier to be invoked |
| 00:25:04 | Araq | memcpy is not a write barrier |
| 00:26:23 | flaviu | But isn't GC single threaded? I'm not sure I understand the purpose of having a write barrier |
| 00:26:37 | Araq | yes |
| 00:26:41 | Araq | you don't understand |
| 00:26:42 | EXetoC | but is it only a little wrong? if so, go for it |
| 00:26:51 | Araq | and yet you pretend to know everything |
| 00:27:05 | Araq | and come up with old stuff like 'new T' |
| 00:27:10 | Varriount | flaviu: But a single core may execute instructions out of order, right? |
| 00:27:16 | Araq | which I explained in the past why it's a bad idea |
| 00:27:19 | Araq | but no |
| 00:27:55 | Araq | it's because "I'm unwilling to break code" |
| 00:28:05 | Araq | even though that has nothing to do with anything |
| 00:28:23 | flaviu | Varriount: Sure, but its designed to be impossible to tell its executing out of order. As far as your program is concerned, it doesn't notice |
| 00:28:23 | flaviu | Araq: I haven't seen your reasoning why its a bad idea in the past |
| 00:28:40 | flaviu | Or I've forgotton |
| 00:28:56 | Varriount | flaviu and I are inquisitive. |
| 00:29:17 | flaviu | Do you have a link or a couple keywords I could use to google? |
| 00:29:32 | Araq | nah, it's all in the IRC logs |
| 00:29:38 | Araq | but here is the short version: |
| 00:30:32 | Araq | "new T" is quite stupid, given that it doesn't work as soon as you need a factory |
| 00:33:03 | * | saml_ quit (Ping timeout: 240 seconds) |
| 00:36:36 | Araq | and what's wrong the current constructors anyway? Foo(field: 1, fieldB: ") ? |
| 00:36:48 | Araq | that you dislike 'ref object'? |
| 00:36:51 | flaviu | I've found the relevent logs http://build.nimrod-lang.org/irclogs/16-02-2013.html |
| 00:36:54 | Araq | seriously? |
| 00:37:04 | flaviu | around 22:00 |
| 00:37:36 | OrionPK | the 'could care less' thing is a generalization |
| 00:37:37 | flaviu | Araq: Not at all. I think it'd become redundant |
| 00:37:40 | OrionPK | not all americans speak that way :P |
| 00:38:29 | flaviu | I also think it has the potential to cause more trouble than its worth, but I'm sure theres ways to mitigate that |
| 00:40:51 | Araq | constructors are functions anyway and it sucks that this is wrong |
| 00:41:16 | flaviu | Araq: If I understand your factory point correctly, I'd also like to say that `new T()` is literally a function that takes a T and returns a ref T. That means that `new factoryForT()` is equally valid |
| 00:41:55 | Araq | this is not at all how 'new' works in C#/Java/C++ though |
| 00:42:16 | Araq | new Foo(a, b).method() works in Java |
| 00:42:22 | Araq | it's parsed as |
| 00:42:25 | flaviu | Only recently IIRC |
| 00:42:34 | Araq | (new Foo(a, b)).method() |
| 00:44:15 | flaviu | I'd also like to mention another idea that would complement having this method very well: making method that shadow a type's name be valid |
| 00:44:15 | flaviu | Much more complicated to implement, but it would effectively allow constructors |
| 00:44:29 | Araq | the point is that 'new T' takes a *type* but for factories this is wrong as a factory returns T or *some subtype of T* |
| 00:44:55 | Araq | new factoryForT doesn't really solve anything |
| 00:45:12 | Araq | as then I need to know I shouldn't pass T to 'new' |
| 00:45:24 | Araq | might as well call factoryForT then |
| 00:45:30 | Araq | without the 'new' |
| 00:45:47 | * | saml_ joined #nimrod |
| 00:46:02 | Araq | and before you mention it |
| 00:46:14 | Araq | yes the T(...) syntax we ended up with has the same problem |
| 00:49:43 | Araq | unfortunately construction is special semantically no matter how hard you try not to make it special |
| 00:52:02 | * | saml_ quit (Ping timeout: 264 seconds) |
| 01:00:30 | * | brson quit (Quit: leaving) |
| 01:00:37 | * | brson joined #nimrod |
| 01:03:27 | * | goobles quit (Quit: Page closed) |
| 01:03:39 | * | saml_ joined #nimrod |
| 01:09:30 | * | gsingh93_ joined #nimrod |
| 01:11:08 | * | ehaliewicz joined #nimrod |
| 01:13:12 | BitPuffin | Araq: again nobody said it's because you are unwilling to break old code that this particular thing is the way it is, you are making a fool of yourself by suggesting it :P |
| 01:14:45 | flaviu | Actually, "BitPuffin: Araq is pretty unwilling to break backwards compatibility, even with small things that are ugly" |
| 01:15:12 | BitPuffin | flaviu: and where in that does that say that this means that this is ugly and this is why this is the way it is? |
| 01:15:37 | BitPuffin | What that explains is that you are unlikely to get your change through, regardless if you are right or not |
| 01:15:50 | BitPuffin | not that this is something that should be fix |
| 01:15:52 | BitPuffin | semantics |
| 01:15:58 | BitPuffin | it's what we do |
| 01:16:26 | BitPuffin | also context |
| 01:16:37 | BitPuffin | I said that I don't really care for one over another |
| 01:16:38 | flaviu | BitPuffin: The context implies that, but I guess the implication wasn't intentional |
| 01:16:46 | BitPuffin | so why would I suddenly hting that this is ugly all of a sudden |
| 01:16:52 | BitPuffin | so no the context doesn't imply that, you are wrong |
| 01:17:13 | flaviu | Ok |
| 01:17:13 | BitPuffin | the sentence on its own implies that |
| 01:17:34 | BitPuffin | or actually no |
| 01:17:36 | BitPuffin | :P |
| 01:17:38 | BitPuffin | it doesn't |
| 01:17:44 | BitPuffin | the sentence on its own speaks about the general case |
| 01:20:12 | flaviu | Araq: I'm still not really sure what you're saying. Can you give a concrete example for clarification? |
| 01:20:26 | * | q66 quit (Quit: Leaving) |
| 01:22:33 | BitPuffin | PFoo(a: 2) doesn't allocate currently does it? |
| 01:22:36 | Araq | flaviu: T(...) has been introduced because we really need it, but at least I didn't make the grammar complex for it |
| 01:22:36 | flaviu | Just to clarify, my `new` idea is not that `new` takes a type. Its that `new` just takes an object from anywhere, and moves it to the heap. `var a: MyType; var b = new a`, the value of a == the value b is pointing out |
| 01:22:43 | flaviu | BitPuffin: Yes, it does |
| 01:22:55 | BitPuffin | even on the heap? |
| 01:23:11 | flaviu | My understanding is that it allocates to the heap |
| 01:23:23 | BitPuffin | hmm oh wait |
| 01:23:26 | BitPuffin | right |
| 01:23:42 | BitPuffin | I'm just used to doing new(PFoo) and then setting values because new let's you set a finalizer |
| 01:24:01 | Araq | 'new T' introduces a weird special parsing rule or else is not like C# |
| 01:24:36 | Araq | and my apologies |
| 01:24:49 | Araq | I didn't understand your 'new' |
| 01:24:57 | flaviu | Araq: My proposal for `new` is literally what you see in that gist, I want that method to go into system.nim without any changes but the fence bugfix |
| 01:25:25 | Araq | what gist again? |
| 01:25:44 | flaviu | https://gist.github.com/flaviut/2ec636b67512acaec79f |
| 01:27:15 | Araq | no way |
| 01:27:19 | Araq | your emit is wrong |
| 01:27:27 | Araq | the real solution is: |
| 01:27:35 | Araq | result[] = obj |
| 01:28:01 | Araq | and btw that you can't take the addr of a parameter is an essential feature of the language |
| 01:28:12 | Araq | and not something we forgot to implement |
| 01:28:28 | BitPuffin | it wouldn't be safe |
| 01:28:35 | flaviu | Thanks, I'm not really sure about the semantics of `[]` so I didn't know thats how you use it. |
| 01:28:44 | BitPuffin | flaviu: think * |
| 01:29:25 | Araq | I need to sleep now, good night |
| 01:29:42 | flaviu | I'm open to that change, and any other you find necessary, the goal of what I said is to clarify that I don't want a language change like that method, I want _that method_ |
| 01:30:07 | f0wl | you want to change more stuff |
| 01:30:19 | BitPuffin | foo *new(foo f) { foo * nf = (foo*)malloc(sizeof(foo)); nf* = f; return nf; } |
| 01:30:26 | BitPuffin | the nf* = f; nf[] = f |
| 01:30:53 | flaviu | f0wl: The other changes I came up with are 100% optional and completely orthogonal to the `new` issue |
| 01:31:04 | flaviu | But would compliment it very well |
| 01:31:06 | BitPuffin | should probably not call it new |
| 01:31:15 | BitPuffin | with the C*'s |
| 01:31:39 | * | ehaliewicz quit (Remote host closed the connection) |
| 01:31:44 | BitPuffin | probably better with something like heap or something |
| 01:31:45 | f0wl | no option to pass finalizer |
| 01:32:08 | BitPuffin | f0wl: very important |
| 01:32:33 | Araq | flaviu: I gave this solution on the forum once |
| 01:32:39 | Araq | called it 'create' perhaps |
| 01:32:42 | Araq | but I said |
| 01:33:04 | Araq | "why is this missing from system.nim then? Because I never need it" |
| 01:33:18 | Araq | so why do *you* need it? |
| 01:33:47 | flaviu | Because I don't want to use type prefixes, and I want to be able to allocate on both the heap and the stack with concise syntax |
| 01:34:20 | Araq | (ref T)(a: 1) |
| 01:34:24 | Araq | T(a: 1) |
| 01:34:29 | Araq | there you go |
| 01:34:49 | Araq | maybe (ref T)(a: 1) doesn't work yet, but that's a bug then |
| 01:35:20 | flaviu | I don't like having parans around `(ref T)`, but I can put up with it |
| 01:35:30 | flaviu | when that syntax works, I'll use that |
| 01:36:03 | f0wl | allocate on both the heap and the stack -- have fun defining this api |
| 01:37:03 | flaviu | f0wl: What do you mean? |
| 01:37:28 | f0wl | defining functions that act on Foo or ref Foo |
| 01:38:06 | flaviu | Oh, I'd just ask for a Foo when I only need read access, and ask for a var Foo when I need to write |
| 01:38:26 | Araq | f0wl: that will get easier with auto-deref |
| 01:38:41 | Araq | but I agree it doesn't come up all that often |
| 01:39:39 | Araq | good night |
| 01:54:29 | * | f0wl quit (Quit: Leaving) |
| 02:15:39 | Varriount | Anyone ever put thought into how enums might be extended, without breaking api code that uses the enum members with case statements? |
| 02:19:23 | * | superfunc joined #nimrod |
| 02:54:17 | * | brson quit (Read error: Connection reset by peer) |
| 03:25:39 | * | superfunc quit (Quit: leaving) |
| 03:25:59 | * | superfunc joined #nimrod |
| 03:34:28 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 03:41:35 | * | saml_ quit (Quit: Leaving) |
| 03:53:35 | * | flaviu quit (Ping timeout: 240 seconds) |
| 03:57:23 | * | superfunc quit (Quit: leaving) |
| 04:18:06 | * | fowl joined #nimrod |
| 05:01:50 | * | vendethiel quit (Quit: q+) |
| 05:13:19 | * | fowl quit (Quit: Leaving) |
| 05:29:30 | * | gsingh93_ quit (Quit: Connection closed for inactivity) |
| 05:40:45 | * | gkoller joined #nimrod |
| 06:03:38 | * | io2 joined #nimrod |
| 06:03:48 | * | io2 quit (Client Quit) |
| 06:05:04 | * | hoverbear quit () |
| 06:05:27 | * | hoverbear joined #nimrod |
| 06:05:28 | * | hoverbear quit (Client Quit) |
| 06:29:22 | * | joelmo joined #nimrod |
| 06:52:26 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 07:38:11 | * | BitPuffin joined #nimrod |
| 07:46:22 | * | MayurYa joined #nimrod |
| 07:46:31 | * | MayurYa quit (Changing host) |
| 07:46:31 | * | MayurYa joined #nimrod |
| 07:58:31 | * | kunev joined #nimrod |
| 08:08:13 | * | ARCADIVS joined #nimrod |
| 08:21:44 | * | foodoo joined #nimrod |
| 09:09:12 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 09:11:27 | * | pafmaf_ joined #nimrod |
| 09:11:28 | * | pafmaf_ quit (Client Quit) |
| 09:11:46 | * | pafmaf joined #nimrod |
| 09:14:05 | * | pafmaf quit (Client Quit) |
| 09:17:16 | * | pafmaf joined #nimrod |
| 09:18:39 | Araq | hi pafmaf welcome |
| 09:18:53 | pafmaf | hi |
| 09:19:04 | pafmaf | (haven't been here in a while) |
| 09:46:08 | * | io2 joined #nimrod |
| 09:46:25 | * | Mat3 joined #nimrod |
| 09:46:28 | Mat3 | hello |
| 09:51:24 | Mat3 | I get an compilation error: |
| 09:51:33 | Mat3 | Error: internal error: GetUniqueType |
| 09:51:46 | Mat3 | No stack traceback available |
| 09:54:16 | * | io2 quit (Ping timeout: 260 seconds) |
| 09:54:17 | Mat3 | I do not know the reason because the error message is to unspecific |
| 09:55:00 | Mat3 | any hint would be nice |
| 09:57:39 | Mat3 | ok, found the error, 'var aIlCpuOpcode = array [0..16, uInt8]' instead of 'var aIlCpuOpcode: array [0..16, uInt8]' |
| 10:00:26 | * | MayurYa quit (Ping timeout: 264 seconds) |
| 10:04:08 | Araq | Mat3: yeah ... I know |
| 10:04:31 | Araq | Varriount: please do me a favour and mark all closure bugs with a new 'closure' tag |
| 10:04:40 | Araq | these are all about to get fixed :-) |
| 10:04:50 | Araq | bbl |
| 10:08:40 | Mat3 | Araq: Can I assume that changing the current error messages to somewhat more specific descriptions is not a trivial task ? |
| 10:15:55 | EXetoC | unspecific indeed, but that's kind of the nature of internal errors. those are always considered bugs |
| 10:29:25 | * | noam__ joined #nimrod |
| 10:31:55 | * | io2 joined #nimrod |
| 10:32:32 | * | noam quit (Ping timeout: 244 seconds) |
| 10:43:58 | Araq | Mat3: indeed |
| 10:44:27 | Araq | well it's not *that* hard to give line information here |
| 10:44:39 | Araq | but the proper fix looks entirely different |
| 10:51:32 | Mat3 | I see |
| 10:55:38 | Araq | in fact I'm thinking of how to support "types as a first class citizen" |
| 10:55:58 | Araq | var x = int should be disallowed |
| 10:56:10 | Araq | but var x = type(int) is not unreasonable |
| 11:00:05 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 11:09:34 | EXetoC | so = instead of : and it's a typedesc |
| 11:19:50 | Araq | that's how it currently is |
| 11:20:05 | Araq | my plan is to require 'type' so that the intention is quite clear |
| 11:25:29 | dom96 | hello |
| 11:27:36 | Araq | hey dom96 |
| 11:28:46 | dom96 | hi Araq |
| 11:29:36 | Araq | dom96: an example that requires nested closures would be good now |
| 11:30:57 | dom96 | Araq: Jester, new-async branch, tests/asynctest.nim |
| 11:31:07 | dom96 | That's perhaps too complicated though |
| 11:31:19 | Araq | bah gist it or something simpler |
| 11:31:31 | dom96 | I can't gist it |
| 11:31:39 | dom96 | Is it so hard to clone the repo? |
| 11:32:05 | Araq | yep |
| 11:32:56 | dom96 | It's easier than me coming up with a new example |
| 11:33:38 | Araq | it's called "distributed thinking" |
| 11:33:59 | Araq | don't let the master brain do everything |
| 11:34:03 | dom96 | no, it's called "araq being lazy" :P |
| 11:36:00 | * | io2 quit (Ping timeout: 260 seconds) |
| 11:39:23 | * | pafmaf joined #nimrod |
| 11:44:45 | dom96 | Araq: https://gist.github.com/dom96/8bd8db6c57a7fa712a14 |
| 11:45:23 | Araq | dom96: ok thanks |
| 11:45:33 | Araq | let's see if that is simple enough |
| 11:49:25 | * | Mat3 quit (Quit: Verlassend) |
| 11:50:20 | dom96 | yay, gradha tested babel. |
| 11:50:29 | dom96 | and found a bug |
| 12:03:00 | NimBot | nimrod-code/babel master 6b03336 Dominik Picheta [+0 ±1 -0]: Fixes #42. |
| 12:06:27 | EXetoC | universe: fixed |
| 12:07:38 | dom96 | hah :D |
| 12:08:11 | dom96 | Life, the Universe and Everything: fixed :) |
| 12:14:07 | * | shevy quit (Ping timeout: 272 seconds) |
| 12:19:02 | * | shevy joined #nimrod |
| 12:21:27 | * | untitaker quit (Ping timeout: 245 seconds) |
| 12:23:37 | * | shevy quit (Ping timeout: 272 seconds) |
| 12:27:04 | * | untitaker joined #nimrod |
| 12:35:01 | * | io2 joined #nimrod |
| 12:35:02 | * | io2 quit (Client Quit) |
| 12:35:26 | * | io2 joined #nimrod |
| 13:26:01 | * | darkf quit (Quit: Leaving) |
| 13:35:38 | * | gkoller quit (Ping timeout: 276 seconds) |
| 13:40:29 | * | shevy joined #nimrod |
| 13:58:38 | * | foodoo quit (Quit: so long and thanks for the fish) |
| 14:46:54 | * | kunev quit (Quit: leaving) |
| 14:47:59 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 14:49:17 | * | kunev joined #nimrod |
| 14:56:17 | * | io2 quit () |
| 15:02:14 | * | kunev quit (Ping timeout: 244 seconds) |
| 15:33:59 | * | Johz joined #nimrod |
| 15:35:39 | * | dom96 quit (Excess Flood) |
| 15:38:37 | * | dom96 joined #nimrod |
| 15:41:43 | * | nahamu left #nimrod ("WeeChat 1.0-dev") |
| 15:44:08 | * | fowl joined #nimrod |
| 16:08:45 | * | pafmaf joined #nimrod |
| 16:12:58 | * | superfunc joined #nimrod |
| 16:13:16 | * | hoverbear joined #nimrod |
| 16:18:42 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 16:23:41 | * | Jesin quit (Quit: Leaving) |
| 16:32:31 | * | noam__ is now known as noam |
| 16:33:34 | * | brson joined #nimrod |
| 16:50:24 | * | io2 joined #nimrod |
| 16:55:37 | * | brson quit (Quit: leaving) |
| 16:55:46 | * | brson joined #nimrod |
| 16:56:44 | * | goobles joined #nimrod |
| 17:00:33 | * | xtagon joined #nimrod |
| 17:02:06 | * | brson quit (Ping timeout: 240 seconds) |
| 17:03:21 | * | brson joined #nimrod |
| 17:15:48 | * | q66 joined #nimrod |
| 17:19:15 | * | Matthias247 joined #nimrod |
| 17:23:19 | * | BitPuffin joined #nimrod |
| 17:36:10 | * | Trustable joined #nimrod |
| 17:38:19 | * | Jehan_ joined #nimrod |
| 17:39:25 | * | kunev joined #nimrod |
| 17:40:50 | * | fowl quit (Quit: someone shoot me) |
| 17:46:01 | * | brson quit (Ping timeout: 244 seconds) |
| 17:51:15 | superfunc | sup Jehan |
| 17:51:44 | * | brson joined #nimrod |
| 17:51:49 | Jehan_ | Hi, superfunc! |
| 17:52:05 | superfunc | Hows it going? |
| 17:55:35 | * | Mat3 joined #nimrod |
| 17:55:43 | Mat3 | Good Day |
| 17:55:59 | superfunc | Hey Mat3, welcome |
| 17:56:09 | Mat3 | hello superfunc |
| 18:00:12 | * | brson quit (Ping timeout: 245 seconds) |
| 18:06:30 | Jehan_ | One of the things that I seriously hate about Dart is how complicated it is to build it from scratch. |
| 18:07:02 | * | brson joined #nimrod |
| 18:08:08 | superfunc | I haven't had to chance to mess with it yet, though I really respect one of the guys working on it |
| 18:09:02 | Jehan_ | I like it a lot, which makes it frustrating how annoying it can be to deploy. |
| 18:09:23 | superfunc | Its posed to be an alternative to JS right? |
| 18:10:02 | Jehan_ | Not really. |
| 18:10:08 | Jehan_ | It is a general purpose language. |
| 18:10:44 | superfunc | Oh ok, I had only heard about in that context. Thats cool |
| 18:11:10 | Jehan_ | Honestly, it's probably more interesting for non-web stuff. :) |
| 18:11:22 | Jehan_ | Or where you need both so that you require only one language. |
| 18:12:23 | Matthias247 | Jehan_: the good thing is that you usally don't need to build it from scratch |
| 18:12:27 | superfunc | That's funny, since their website calls it a "web language" lol |
| 18:12:34 | Jehan_ | But one of the strengths of Nimrod is that you essentially can deploy the entire compiler with a project assuming that there is a functioning C compiler. |
| 18:13:01 | Jehan_ | Matthias247: Depends. If you write tools that you want arbitrary other people to run, you do need that. |
| 18:13:05 | * | nequitans_ joined #nimrod |
| 18:13:32 | superfunc | Its one of my favorite parts about Nimrod. |
| 18:13:43 | * | hoverbea_ joined #nimrod |
| 18:14:20 | Jehan_ | superfunc: Having it as a JS replacement was probably the original motivation, but the library and the language go way beyond what you need for that. |
| 18:14:37 | Matthias247 | I guess if you are targetting windows or osx then binary dart is fine. linux - don't know about libc dependencies |
| 18:14:59 | Matthias247 | and for embedded dart is simply not supported - contrary to nimrod |
| 18:15:13 | Jehan_ | Matthias247: Has to run on Windows, OS X, Linux, Solaris, and BSD at least. |
| 18:15:23 | superfunc | Jehan_: That's cool, I'll throw it on the never ending list of things to learn (^.^); |
| 18:16:10 | Matthias247 | don't know if solaris and bsd support is worthwhile :) |
| 18:16:14 | Jehan_ | superfunc: I've seriously been toying with using it as a kinda-sorta scripting alternative to Python and Ruby. |
| 18:16:18 | Matthias247 | in terms of user-base |
| 18:16:33 | Jehan_ | Matthias247: Hard requirement for me. |
| 18:16:37 | * | hoverbear quit (Ping timeout: 264 seconds) |
| 18:16:47 | Matthias247 | somewhere was written that it is also considered for android. But I guess that's more a rumor |
| 18:17:14 | Matthias247 | I would however like it. More than java |
| 18:17:54 | Jehan_ | Hmm, I'm not sure that it's well-suited for Android. |
| 18:18:03 | Jehan_ | On the other hand, the same could have been said about Dalvik. |
| 18:18:43 | Matthias247 | I think they could add support for Binder IPC and therefore access to most of android framework quite easily |
| 18:18:46 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 18:18:46 | Jehan_ | To this day, I'm not sure why Google considered it so important to have a JIT language on a mobile platform. |
| 18:18:57 | Jehan_ | So important that they disregarded all alternatives, too. |
| 18:19:05 | Matthias247 | but I don't know if they would like to rewrite the whole UI framework |
| 18:19:54 | Matthias247 | the question is what were the alternatives? C++? Don't think so, if they want a big developer base |
| 18:20:05 | Matthias247 | Mono would have been nice :) |
| 18:20:15 | Jehan_ | Matthias247: Why a JIT in the first place? |
| 18:20:31 | Jehan_ | It's not like ARM hardware is oozing spare processor cycles. |
| 18:21:18 | Jehan_ | Especially given how patents prevent them from optimizing Dalvik to the maximum extent possible. |
| 18:21:21 | superfunc | There was a post on reddit about Go getting support through the NDK |
| 18:21:34 | superfunc | I'd much rather write Go than Java |
| 18:22:14 | Matthias247 | Jehan_: but what be a non-jitted easy-to-use and high-performant language? |
| 18:22:18 | Jehan_ | superfunc: Depends on the application domain. |
| 18:22:54 | Jehan_ | Matthias247: There are enough around, and they could easily have designed one themselves? |
| 18:23:10 | superfunc | In general, I just find it more enjoyable. If I am working alone, I don't mind Java, but whenever I have to collaborate with others, their code seems to bloat really really fast |
| 18:23:16 | Matthias247 | Jehan_: examples? :) |
| 18:23:20 | Jehan_ | High performance is only a function of the backend, more or less. |
| 18:23:37 | Jehan_ | Matthias247: Take Delphi, add a GC, done. |
| 18:24:08 | superfunc | Anon. Classes everywhere, though lambdas may mitigate that |
| 18:24:23 | Matthias247 | I think Java was mostly for having a broad developer base. Which you don't have when you take something very special or make your own thing |
| 18:24:56 | Jehan_ | Matthias247: Not according to the letters that were shown in Oracle v. Google. |
| 18:26:05 | Jehan_ | Even so, they could have just statically compiled the Java code. |
| 18:26:36 | Jehan_ | But Android, like iOs, is a platform where you can pretty much pick your own language and people WILL adjust. |
| 18:26:53 | Matthias247 | yes, that would have been another option |
| 18:26:59 | Jehan_ | It's not like Objective-C had a whole lot of mindshare prior to iOS. |
| 18:27:39 | Matthias247 | yes. But Apples Market position is and was different |
| 18:27:57 | Matthias247 | people bought iphones because they are cool, not because of objective-c or something else |
| 18:28:35 | Matthias247 | and the developers simply have to take the only tool that was available to make apps for it. And they do it - because they want to make money |
| 18:28:36 | Jehan_ | And the same would have gone for Android customers. |
| 18:28:47 | Matthias247 | android startet with a very small market share |
| 18:29:07 | Matthias247 | Could have easily failed when nobody wanted to do apps for it |
| 18:29:09 | Jehan_ | Nobody bought Android phones because apps were writtten in Java. |
| 18:29:41 | Mat3 | hmm, after take a first look at it, I see no real advantage of Dart against Javascript |
| 18:29:49 | Jehan_ | If anything, they hamstrung their market position by using an inefficient JVM implementation. |
| 18:30:07 | superfunc | Has anyone messed around with getting nimrod working on android? |
| 18:30:17 | Jehan_ | Mat3: Type checking, the fact that it has a standard library for non-web stuff? |
| 18:30:25 | superfunc | TYPES |
| 18:30:28 | superfunc | TYPES MATTER |
| 18:30:32 | Jehan_ | superfunc: Would be a lot of work. |
| 18:30:58 | Mat3 | that's not an advantage in my opinion |
| 18:31:13 | superfunc | Jehan_: I may mess with it once we hit 1.0 |
| 18:31:28 | Matthias247 | static typing is a hudge advantage for me |
| 18:31:31 | superfunc | Though getting Qt4 or Qt5 bindings is higher on my list after finishing my game |
| 18:31:35 | Jehan_ | Mat3: Totally fine, but there are people who prefer typed languages. |
| 18:31:37 | goobles | why wouldn't nimrod work on android, doesn't it compile to c? |
| 18:31:39 | Matthias247 | and dart has a very well thought out standard library |
| 18:32:05 | superfunc | Matthias247: Yes |
| 18:32:16 | Jehan_ | goobles: It would, the problem is creating the library bindings. |
| 18:32:48 | Jehan_ | Possibly bootstrapping stuff, too, I don't know enough about Android on the native level, but nothing unsurmountable there. |
| 18:33:04 | superfunc | Jehan_: Couldn't you just write logic in Nim and call to it through the NDK with the UI layer handled in Java |
| 18:33:10 | Araq | we have an andriod project in the distribution |
| 18:33:26 | Jehan_ | superfunc: No idea. |
| 18:33:41 | Araq | so yes, nim works on android |
| 18:33:47 | Jehan_ | I have to say, I'm a smartphone luddite, so this is mostly just of theoretical interest to me. |
| 18:34:11 | goobles | i think you can make 100% native apps now for android |
| 18:34:17 | superfunc | Yeah, I own a blackberry right now for gods' sake |
| 18:34:27 | Jehan_ | goobles: I know you can, just not sure what is involved. |
| 18:34:33 | Matthias247 | the C standard library is different between android and linux. Therefore not every linux code compiles on android |
| 18:34:54 | Matthias247 | glibc vs bionic |
| 18:36:51 | Matthias247 | superfunc: of course you could do such mixed projects on Android. The main problem would be that the build and distribution process is much harder than with only java code |
| 18:37:15 | Jehan_ | Which reminds me that I'm still curious why a JVM backend for Nimrod would be impossible. Not very efficent, sure, but why impossible? |
| 18:38:09 | Araq | afaik the unsafe stuff doesn't really work well with the rest of Java's object model |
| 18:38:52 | Araq | but ok, "impossible" is overblown |
| 18:38:58 | Jehan_ | Araq: True, but the same goes for the CLR. |
| 18:39:06 | Jehan_ | At least in part. |
| 18:39:09 | Araq | no the CLR is much better |
| 18:39:57 | Jehan_ | Araq: No disagreement that the CLR is tons better as a backend, but that particular issue it doesn't handle much better? |
| 18:40:30 | Jehan_ | At least I can't see how one would implement copyMem, for example. |
| 18:41:20 | Araq | what's the problem? it supports arbitrary casts |
| 18:41:52 | Araq | and pointer arithmetic too |
| 18:42:58 | Jehan_ | Hmm, isn't the implementation somewhat constrained with respect to that, too? |
| 18:43:19 | Jehan_ | Pointer arithmetic is doable on the JVM, too, just very inefficient. |
| 18:44:42 | dom96 | I have an iOS app written in Nimrod on my iPad and it works well. As for Android, it also worked last time I tested it (albeit in the emulator). Gradha is the man to speak to about this. |
| 18:44:51 | Mat3 | as I know the CLR features a very rich type model (the stack ISA however is as inefficient and obsolete than the JVM one) |
| 18:46:01 | Araq | Jehan_: CRL supports cast[pointer](myobject), JVM does not |
| 18:46:33 | Araq | that means you pretty much need to emulate another virtual machine on the JVM |
| 18:46:50 | Araq | and have no useful interop with Java libraries |
| 18:47:06 | Araq | you can compile C to the JVM with this approach |
| 18:47:18 | Araq | but it's completely unuseful |
| 18:47:43 | Jehan_ | Araq: You could do pointers as pairs (reference to underlying array, offset). |
| 18:48:05 | Araq | that's what we do for the JS backend, for some pointer types |
| 18:48:07 | Jehan_ | Pointer arithmetic for other stuff is undefined in C, after all. :) |
| 18:49:01 | Jehan_ | But I'm not a big fan of the JVM myself, mostly just playing devil's advocate. |
| 18:49:05 | Araq | yes fat pointers are a solution for pointer arithmetic, but not for the missing cast primitive |
| 18:50:07 | Araq | but this could all be wrong anyway, Java's unsafe stuff evolves too |
| 18:50:13 | goobles | jvm zzz, compile it to lua! |
| 18:50:13 | Araq | and I'm not up to date |
| 18:50:14 | Jehan_ | And I'd have to look up the ECMA spec myself, but I'm not sure if you really can do arbitrary casts in the CLR. |
| 18:50:46 | Jehan_ | Well, there's sun.misc.Unsafe .. |
| 18:51:58 | Mat3 | goobles: because of LuaJIT this would be indeed a good choice except, that the Lua VM documentation is poor |
| 18:52:18 | goobles | not the VM, just lua code |
| 18:52:21 | Jehan_ | One concern with arbitrary pointer casts in the CLR would also be that it'd be tricky to get pinning right. |
| 18:52:37 | goobles | the VM bitcode isn't even the same between lua/luajit |
| 18:52:46 | Mat3 | goobles: I so not see how a language like Nimrod would compile to Lua well |
| 18:53:06 | goobles | it probably would suck ya |
| 18:57:48 | Mat3 | well, Lua is extensible- instead of the mess compiling Niomrod to Lua, the Lua environment can be extended into a Nimrod friendly IL representation |
| 18:58:07 | Mat3 | ^Nimrod |
| 18:58:14 | goobles | make it so you can run a nimrod program, change the nimrod code while it is running, never have to restart;0 Nimrod would replace obj/java yaahh |
| 18:59:06 | goobles | a static typing lua(nimrod) would be pretty sweet |
| 18:59:26 | Mat3 | probably a good strategy |
| 19:00:17 | * | superfunc quit (Quit: leaving) |
| 19:00:18 | * | Mat3 I would extend LuaJIT instead of the plain Lua sources |
| 19:01:01 | goobles | luajit can do some tricks where it removes allocations it might not be as bad as you would think to just compile into lua |
| 19:01:14 | goobles | but the lua GC don't scale very far |
| 19:01:21 | Araq | Mat3: I would do the same, but luajit's code is really hard to follow |
| 19:01:31 | Jehan_ | What Araq said. :) |
| 19:01:43 | * | kunev quit (Quit: leaving) |
| 19:02:03 | Araq | goobles: the JS backednd has been designed to be able to produce Lua code instead of JS as well |
| 19:02:03 | Jehan_ | It's also why I'm reluctant to invest much in LuaJIT. It's still essentially a one-man project, from what I know. |
| 19:02:22 | Araq | the plan was to use LuaJIT for the new compiletime evaluation engine |
| 19:03:28 | Araq | but when I wrote vm.nim I was fed up with code generators that munge strings |
| 19:04:17 | Araq | also I was afraid to debug this nimrod->LuaJIT->unsafe code for the FFI stack ;-) |
| 19:06:07 | Mat3 | ok, understandable. I had studied LuaJIT some time ago (specially the assembler version of its interpreter) |
| 19:06:44 | * | pafmaf joined #nimrod |
| 19:09:34 | Mat3 | the ISA is still somewhat similar to the standard Lua VM which implements a canonical RISC encoding (like MIPS 32) |
| 19:09:55 | Araq | the ISA is not the hard part of it ;-) |
| 19:10:38 | Araq | Jehan_: that luaJIT is a one man project wouldn't be a problem if Mike hung out in IRC |
| 19:10:39 | Mat3 | yes. My point is that this ISA would be no more difficult to handle than any native-code compiler for common RISC architectures |
| 19:11:05 | Jehan_ | Araq: Possibly. |
| 19:11:29 | Jehan_ | That said, he's both brilliant and productive. Didn't mean this to be criticism of his person. |
| 19:14:02 | Araq | He is also not a single person but a team of developers :P |
| 19:14:48 | Jehan_ | ? |
| 19:14:59 | goobles | 0-o |
| 19:15:10 | Mat3 | ciao |
| 19:15:11 | EXetoC | he cloned himself? |
| 19:15:18 | EXetoC | Mat3: bai |
| 19:15:26 | * | Mat3 quit (Quit: Verlassend) |
| 19:15:56 | Araq | well rumors exist he doesn't exist :P |
| 19:16:08 | Araq | but he is a team |
| 19:16:54 | * | Puffin joined #nimrod |
| 19:17:17 | * | fowl joined #nimrod |
| 19:19:05 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 19:30:24 | * | ARCADIVS joined #nimrod |
| 19:30:54 | dom96 | hi ARCADIVS |
| 19:31:12 | ARCADIVS | Hello |
| 19:41:35 | * | gkoller joined #nimrod |
| 19:41:55 | Varriount | Hello everyone! |
| 19:42:32 | Varriount | :D |
| 19:45:04 | dom96 | hey Varriount |
| 19:45:49 | Varriount | dom96: I have filemon.nim done, however there's some sort of memory leak occuring that I'm trying to track down. |
| 19:46:28 | Varriount | Araq: I don't suppose there's any easy way to see what allocations are hanging around? |
| 19:47:11 | Araq | Varriount: no, but it's a planned feature |
| 19:47:49 | Araq | but the leak might become a crash with --gc:markAndsweep |
| 19:48:06 | Varriount | Thanks, I'll try it. |
| 19:48:19 | Araq | you really shouldn't store closures, refs, strings in a ptr |
| 19:48:34 | Araq | dom96 had the same bug with the OVERLAPPED struct |
| 19:49:04 | Varriount | I'm not using pointers for anything other than interfacing with some system code. |
| 19:49:13 | Varriount | Mostly string conversion. |
| 19:55:09 | Varriount | Hopefully the problems in my own code, and not the asyncdispatch code... |
| 19:59:46 | Varriount | Araq: Should GC_fullCollect() normally error? |
| 20:00:01 | Araq | no? |
| 20:00:23 | Araq | error in what way? crash? |
| 20:00:43 | Araq | oh you mean that it doesn't clean up everything |
| 20:00:47 | Araq | well yes |
| 20:01:00 | Araq | it can leave lots of stuff alive which you know is dead |
| 20:01:11 | Araq | thanks to the conservative stack marking |
| 20:01:21 | Varriount | Araq: Yes, it crashes the program |
| 20:01:36 | Araq | well it shouldn't |
| 20:01:50 | Varriount | Hm, then it's probably something on my end. |
| 20:04:53 | goobles | why u crash nimrod varriount? |
| 20:05:02 | goobles | stop you that |
| 20:05:23 | Varriount | goobles: Because nimrod ate my yogurt. |
| 20:09:37 | * | brson quit (Quit: leaving) |
| 20:10:12 | * | brson joined #nimrod |
| 20:13:32 | Varriount | That was... odd |
| 20:14:22 | goobles | brson whats up with rust |
| 20:14:41 | Varriount | A procedure which was only supposed to be called once was called 3 times. |
| 20:15:00 | goobles | is it recursive ! |
| 20:15:17 | Varriount | No... |
| 20:16:04 | Varriount | Hm.. I wonder if capturing a parameter which is a closure in another closure is causing the problem... |
| 20:16:24 | goobles | i like closures they are best |
| 20:16:34 | Varriount | Indeed. |
| 20:16:34 | goobles | you need not fear the closure |
| 20:18:34 | brson | goobles: lots of meetups happening. one this week in sf. still trying to finalize core semantics |
| 20:21:15 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 20:25:52 | fowl | i wrote a thing for lua interop |
| 20:25:55 | fowl | https://gist.github.com/fowlmouth/fa6e3498d39e7c81c9dc |
| 20:26:05 | fowl | will write something similar for python later |
| 20:31:35 | Varriount | Gah. How am I supposed to debug this? |
| 20:31:53 | * | hoverbear joined #nimrod |
| 20:31:55 | * | ARCADIVS joined #nimrod |
| 20:32:01 | * | hoverbear quit (Max SendQ exceeded) |
| 20:32:17 | fowl | Varriount, with an iron will and a stolid heart? |
| 20:32:30 | Varriount | Araq: For some reason, the GC is crashing when a particular closure (which calls GC_fullCollect) is called 3 times |
| 20:32:40 | * | hoverbear joined #nimrod |
| 20:33:12 | dom96 | Varriount: Show us the code |
| 20:34:21 | * | hoverbea_ quit (Ping timeout: 255 seconds) |
| 20:35:58 | Varriount | dom96, Araq: https://gist.github.com/Varriount/b53e67ad749793bdfc38 |
| 20:36:26 | Varriount | Oh, wait, forgot the other module |
| 20:39:45 | dom96 | Varriount: I think you're missing a GC_ref in watchDir |
| 20:43:14 | Varriount | dom96: Nope. |
| 20:43:27 | Varriount | dom96: The closure itself performs an implicit ref. |
| 20:44:05 | Varriount | dom96: Anyway, adding a ref/removing the decref still causes the crash. |
| 20:46:18 | dom96 | what removes the crash? |
| 20:46:28 | dom96 | (and causes the memory leak you mentioned) |
| 20:47:08 | * | gkoller quit (Quit: gkoller) |
| 20:50:58 | Varriount | dom96: Well, I don't know what causes the memory leak, other than removing the entire closure. |
| 20:51:45 | Varriount | The crash results from calling GC_fullCollect, but that's just an artificial speedup of whatever causes the crash. |
| 20:52:23 | Varriount | Even without GC_fullCollect, the crash happens (it just takes a lot longer to happen. |
| 20:52:36 | Varriount | I'm thinking that maybe it's something cyclic? |
| 20:56:31 | * | superfunc joined #nimrod |
| 21:02:43 | Varriount | I'm gonna see if stuffing everything implicitly captured in the closure into the change handle will work. |
| 21:20:06 | Varriount | Araq: Is there anyway to get more information from the GC about what it's choking on? Say, compiler build flags or something? |
| 21:27:12 | * | Jehan_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:28:21 | * | superfun1 joined #nimrod |
| 21:28:45 | * | superfun1 quit (Client Quit) |
| 21:29:10 | * | superfunc quit (Quit: leaving) |
| 21:29:30 | * | superfunc joined #nimrod |
| 21:29:35 | Araq | Varriount: lots of things |
| 21:30:16 | Araq | start with -d:useGcAssert -d:useSysAssert |
| 21:39:31 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 21:41:13 | * | Johz quit (Ping timeout: 264 seconds) |
| 21:42:03 | * | Puffin quit (Ping timeout: 240 seconds) |
| 21:42:29 | * | Puffin joined #nimrod |
| 21:45:51 | superfunc | ls |
| 21:46:01 | superfunc | whoops |
| 21:53:35 | * | io2 quit () |
| 21:53:37 | * | superfunc quit (Ping timeout: 272 seconds) |
| 21:55:54 | Varriount | Araq: Turning on GcAssert did something. I'm getting a new traceback which mentions GcUnref |
| 21:58:54 | Varriount | Araq: Yay! Thanks for the advice. One of the structure's reference count was being decreased by an outside force. |
| 22:03:14 | * | Trustable quit (Quit: Leaving) |
| 22:05:18 | Araq | an outside force? |
| 22:06:41 | Varriount | asyncdispatch |
| 22:07:26 | Varriount | poll() decrements the reference count of the Overlapped structure it processes. |
| 22:27:09 | * | EXetoC quit (Read error: No route to host) |
| 22:33:06 | * | EXetoC joined #nimrod |
| 22:46:42 | * | ARCADIVS joined #nimrod |
| 22:59:30 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:00:31 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 23:05:32 | * | ARCADIVS joined #nimrod |
| 23:12:09 | * | darkf joined #nimrod |
| 23:12:25 | * | nequitans_ quit (Ping timeout: 264 seconds) |
| 23:15:06 | * | pafmaf quit (Quit: Verlassend) |
| 23:24:14 | NimBot | nimrod-code/babel master 99ae796 Dominik Picheta [+0 ±1 -0]: Updated developers docs. |
| 23:24:14 | NimBot | nimrod-code/babel master abb0e22 Dominik Picheta [+1 ±0 -0]: Added changelog. |
| 23:25:24 | * | hoverbear quit () |
| 23:27:51 | * | fowl quit (Quit: Leaving) |
| 23:28:52 | * | flaviu joined #nimrod |
| 23:33:45 | NimBot | nimrod-code/babel refs/tags/v0.4 05ac7d5 Dominik Picheta [+0 ±2 -0]: Version 0.4.0 |
| 23:34:19 | * | fowl joined #nimrod |
| 23:34:27 | * | dorei joined #nimrod |
| 23:36:08 | dom96 | https://github.com/nimrod-code/babel/releases/tag/v0.4 |
| 23:36:10 | dom96 | :D |
| 23:36:29 | * | Joe_knock joined #nimrod |
| 23:36:40 | * | Demos joined #nimrod |
| 23:37:10 | Araq | dom96: congratulations! |
| 23:37:21 | dom96 | thanks! |
| 23:39:46 | NimBot | nimrod-code/babel master 05ac7d5 Dominik Picheta [+0 ±2 -0]: Version 0.4.0 |
| 23:54:38 | dom96 | http://forum.nimrod-lang.org/t/482 |
| 23:54:44 | dom96 | voila |
| 23:55:31 | dom96 | *cricket sound* |
| 23:55:41 | shevy | is there a central repository for babel packages? |
| 23:55:57 | flaviu | shevy: github.com/nimrod-code/packages |
| 23:56:37 | flaviu | dom96: I had irc closed, so I was a bit late to see it |