<< 25-05-2014 >>
00:05:19*flaviu1 quit (Quit: Leaving.)
00:06:27*flaviu1 joined #nimrod
00:07:04*aboutGod joined #nimrod
00:12:10*aboutGod left #nimrod (#nimrod)
01:06:20dom96Aww. We didn't get to hear aboutGod.
01:06:44Araqhe'll return
01:07:20*dom96 was going for a pun there
01:09:02Araqwell you failed
01:09:49dom96Araq: shhhh
01:10:13dom96Araq: Just sleep
01:11:03flaviu1\me applies chloroform
01:11:08*flaviu1 applies chloroform
01:16:52Araqgood night
01:19:16flaviu1night
01:37:49*Kazimuth joined #nimrod
01:39:48VarriountHi Kazimuth
01:40:29Kazimuthhalloo
01:49:24VarriountHm. Should 'ptr void' be allowed? Or should the 'pointer' datatype be enforced?
02:05:30fowlnot allowed
02:13:35*caioariede joined #nimrod
02:55:17*flaviu1 quit (Ping timeout: 252 seconds)
02:55:54VarriountHi caioariede
03:00:08*epsylon quit (Ping timeout: 252 seconds)
03:07:47*superfunc joined #nimrod
03:14:02*brson joined #nimrod
04:18:49*boydgreenfield joined #nimrod
04:19:23*Demos__ quit (Read error: Connection reset by peer)
04:22:54*Jesin joined #nimrod
04:23:10*Kazimuth quit (Remote host closed the connection)
05:00:40*boydgreenfield quit (Quit: boydgreenfield)
05:09:29*brson quit (Quit: leaving)
05:38:35VarriountAraq: Do you have any plans to document the compiler internals, so newcomers will be able to more easily contribute to bug fixes?
05:41:59fowlVarriount, ptr T should dereference to T, you can't dereference void
05:42:16fowlthats my rationale
05:42:21fowlthat was in the buffer for a long time
05:42:31Varriountfowl: Yes, and I agree
06:05:01*bjz quit (Ping timeout: 240 seconds)
06:05:45*bjz joined #nimrod
06:41:04*hoverbear quit ()
06:46:06*boydgreenfield joined #nimrod
07:46:41*superfunc quit (Ping timeout: 252 seconds)
08:24:35*bjz quit (Ping timeout: 276 seconds)
08:31:18Araq"ptr void" is not a valid type in nimrod
08:31:30Araqthe compiler needs to enforce that, that's all
09:03:46*Varriount|Mobile joined #nimrod
09:05:17Varriount|MobileAraq: Where would the compiler enforce not using 'ptr void'? Somewhere in the semantic checking process I presume?
09:05:31AraqVarriount|Mobile: people don't read the docs we already have about the compiler's internals
09:06:10AraqI'm not sure more docs would help
09:06:35Varriount|MobileAraq: There's no way to know that.
09:06:53Araqalso it seems to me everybody needs to make the first hand experience that changes break things
09:07:45Varriount|MobileAraq: I'm talking about documenting the procedures, constants, and variables in the compiler source code, so people have some idea what proc X does, and why it's used
09:08:12Araqmost of these are in ast.nim and documented
09:08:24Varriount|MobileOtherwise people have no idea how to go about fixing a compiler bug.
09:08:42Araqusage tracking is always trivial, we ensure nimgrep finds everything
09:08:52Araqwe don't do crazy reflection stuff
09:09:19Varriount|MobileAraq: And what of procedures? 90% of the procedures in the compiler's source code are undocumented.
09:09:49Varriount|MobileI'm not talking about reflection..
09:11:22Varriount|MobileLet me put it this way: The Rust compiler code is documented very well, so it is no surprise that more than one or two people actually contribute to the compiler code.
09:11:53Araqok then let's add docs *shrug*
09:12:10AraqThe Rust compiler also has a team of professionals working on it ...
09:12:41Araqyou know ... people that might even be paid to do it ...
09:13:06Araqiirc the Rust team is bigger than the Go team
09:13:38Varriount|MobileAraq: Which I've been doing. Unfortunately, just like a newcomer, I don't know what most of the compiler procedures are for, exactly.
09:13:39Araqbut that's no wonder really, they are doing language design by brute force
09:14:18AraqI'm glad they finally seem to have got a decent design though
09:14:32*Jesin quit (Remote host closed the connection)
09:14:35Varriount|MobileAraq: Yes, but Rust is open source - They also have people *outside* that official team contributing
09:15:33*Jehan_ joined #nimrod
09:16:12Varriount|MobileAraq: What I'm asking is that, after you've finished with your current parallelization stuff, could you please spend some time documenting the compiler internals?
09:17:39Varriount|MobileAnd by documenting, I mean giving procedures doc-comments which explain what they do and what they are used for.
09:17:43AraqVarriount|Mobile: I'd rather skype with you and explain things and make you document them
09:17:54Jehan_Heh. :)
09:18:27Varriount|MobileAraq: If that is what is takes, I'm willing to do that.
09:19:06Jehan_Varriount|Mobile: Since I have you here, I think the fix that you applied to queues.nim doesn't actually fix the underlying issue.
09:19:22Araqoh yeah ... Jehan_ is right
09:19:42Araqthe problem is that the compiler's source code only accepts a single "friend" module
09:20:33Araqand now that exported templates are allowed to access hidden fields that overwrites the friend
09:21:50Araqhmm lets see "friend" is not a visible concept in the language
09:22:28Araqbetter we document it in the compiler. I'm sure people will find that comment in 75_000+ lines of code :P
09:23:04Jehan_Araq: Somewhat unrelated, I'm also afraid that I don't have an easy solution to offer for the parseFloat issue. I still thought it was worthwhile getting the ball rolling.
09:23:35AraqJehan_: well you did. parseFloat needs to become a builtin
09:24:38Jehan_If you want, I can also rewrite it to remove the dependency on locale.h.
09:24:57Varriount|MobileAraq: I'm sure someone would look in the area of procedures that deal with module exportation, if they actually knew what those procedures were.
09:25:27Jehan_Araq: But getting around using strtod() or equivalent functionality (e.g., sscanf()), would be a major undertaking.
09:27:35AraqVarriount|Mobile: compiler/importer.nim
09:28:02Araqthat's however not at all where the "friend" concept is used
09:29:05AraqJehan_: iirc Ruby copied and adapted the code from GNU's code, but ok let's use strtod()
09:29:38Araqno idea how they could make that locale dependent though, it's a braindead design
09:29:42Jehan_Hmm, afaik the Ruby strtod() is broken also. At least the last time I looked at it.
09:29:49Jehan_And has nothing to do with the GNU version.
09:29:57Araqbut then .NET does the same ...
09:31:03Jehan_Don't get me started on the performance issues of StartsWith() in C# with the standard culture ...
09:32:46AraqVarriount|Mobile: I'd rather vastly improve doc/intern.txt and not document single procs
09:33:16Araqbut instead give a decent overview about the things that don't change much
09:33:28Varriount|MobileAraq: But that provides only a high level overview of the compiler architecture
09:33:38Jehan_Now that I look at it, Ruby's current version actually uses David M. Gay's dtoa.c.
09:34:08Jehan_Varriount|Mobile: Personally, that kind of bird's-eye view is what I'd be looking for most of the time.
09:34:33Jehan_I can generally figure out what a piece of code does, but not necessarily how the various modules work together.
09:35:02Varriount|MobileAraq: A lower level, more detailed set of information is needed for things like fixing bugs.
09:36:24Varriount|MobileJehan_: Great, tell me how I should go about fixing genRepr so that it supports generating a string description of types.
09:36:34*Matthias247 joined #nimrod
09:37:33Jehan_Varriount|Mobile: Fair point, in an ideal world everything would be documented everywhere (and organically grown code tidied up). But with limited resources, that's what I'd like to see prioritized.
09:38:00VarriountJehan_: Why?
09:38:24VarriountJehan_: What does the high-level overview provide in terms of helping other's contribute to nimrod?
09:39:08Jehan_Varriount: Because non-local properties are the aspects of any software system that are the most difficult to derive by yourself.
09:41:31VarriountJehan_: I'm not sure I understand that statement. Could you please clarify?
09:43:02Jehan_Varriount: Figuring out what a procedure does is generally a matter of a combination of inspecting the code plus printing its state during a few trial runs. It's a fairly straightforward procedure with limited time investment.
09:43:32Jehan_Figuring out global (i.e., cross-module) properties and invariants is comparatively harder.
09:44:03VarriountExcept when the code consists of 50-200 lines, or does something fairly generic to a node datatype.
09:44:48Jehan_Incidentally, what I'd like to see more information on is how to effectively display parts of the compiler's internal state.
09:45:21Jehan_Varriount: I don't disagree, but I'm talking about priorities, not an absolute either-or situation.
09:45:40VarriountJehan_: And you are right, however your argument also supports documenting compiler procedures.
09:45:42Jehan_Yes, you want to document unintuitive code, too (or rewrite it so that it's easier to understand).
09:46:35Jehan_I'm talking about how to allocate finite development resources, and I don't mean to spend them exclusively on the big picture.
09:46:42AraqJehan_: there is 'debug' for PType, PSym and PNode and 'renderTree' for PNode
09:46:52Jehan_But that's where my priorities would lie.
09:46:54Araqand typeToString for PType
09:47:28Araq'debug' often is overwhelming
09:47:35Jehan_Araq: Great, we should add that information to the documentation. :)
09:47:55VarriountJehan_: There are many compiler procedures where it is possible to see what is being done, but why it is being done and what external effects the procedure has are unclear.
09:48:33Jehan_Varriount: Yes, and I'm not saying that this stuff shouldn't be documented. In fact, it probably should. The question is: Where do you get started?
09:48:52fowlJehan_, the github wiki is severely underused imo
09:49:15VarriountJehan_: By documenting procedure's as they are being changed.
09:49:41Jehan_fowl: Probably. I have to admit, part of my problem is that I'm not a big fan of Github (yeah, I know, burn me at a stake :) ).
09:50:17VarriountJehan_: For example, zahary and Araq could add reasonable doc-comments to each compiler procedure they touch whilst in the course of adding features, fixing bugs, etc.
09:51:29VarriountAraq, Jehan_: I have talked with people who want to use Nimrod for various projects, but have been stopped due to some bug or other. They would be willing to try and fix the bug, however they don't know where to start.
09:52:53VarriountAt best they have a stack trace to follow, and are dumped into an undocumented area of the compiler source code. At worst, they know what is wrong, but have no idea how to go about fixing the bug.
09:53:07Jehan_Varriount: Yeah, I completely sympathize. That's also a problem I run into myself often enough.
09:53:24VarriountThe latter situation, I must admit, is something that a higher level explanation would help with.
09:53:37fowlbetter errors would be nice
09:53:57fowli want to know what line caused the compiler to segfault so i can fix it :D
09:54:03fowlmy line
09:54:13Varriountfowl: koch boot --stackTrace:on
09:54:26Jehan_Varriount: My biggest problem has always been being able to inspect the compiler's state for that.
09:54:28fowlVarriount, *my line*
09:54:54Jehan_fowl: That information is not always easy to extract.
09:55:00Varriountfowl: Then print out the info of the node, type, or piece of program ast nearest to the segfault.
09:56:18Jehan_fowl: You can get the lineinfo out of the AST (which is a tree of PNode/TNode in ast.nim).
09:56:27fowlsegfault might require that, i should get line info from internalasserts though
09:57:16EXetoC--stackTrace:on is the default I think. anyway, I use 'koch temp' when debugging
09:58:15EXetoCwhich generates bin/nimrod_temp
10:00:46VarriountHere's what I've been using, I'm sure there's a bash equivalent: " (koch temp -d:debug) && (.\bin\nimrod_temp.exe c --run testcase.nim) "
10:03:36Araqalright will document things
10:03:55Araqlet's see if it helps
10:04:04Araqneed to go see you later
10:06:09EXetoCVarriount: I don't think 'debug' is used for anything, but you are indeed omitting release
10:06:53VarriountEXetoC: debug makes the compiler output a stacktrace when a regular error is thrown (like a syntax error)
10:08:16EXetoCgonna see if that's mentioned anywhere. couldn't find anything with grep
10:08:34VarriountEXetoC: msgs.nim
10:09:23VarriountLine 729
10:10:05EXetoCmy search was to specific. I expected 'when' to be used
10:20:24*ehaliewicz quit (Remote host closed the connection)
10:24:24fowlwhat is defined while bootstapping? Is it `bootstrapping`?
10:24:50VarriountI think it's 'booting'
10:25:51*silven joined #nimrod
10:34:05dom96'morning
10:34:28Varriountdom96: Morning. Want to chat on the VNUG?
10:35:11dom96Varriount: Sure, but give me a couple of minutes, need to grab some food
10:36:50VarriountHi silven
11:09:37silvenyo
11:35:41VarriountAraq: How should I go about allowing or disallowing repr to accept typedesc?
11:51:11Jehan_Varriount: Out of curiosity, what do you want repr() to output for types? More than typetraits.name?
11:51:54VarriountJehan_: Probably the type name, plus the underlying value of the type (an int?)
11:53:10Jehan_Varriount: I was mostly curious about the use case you had in mind and why you needed more than overload repr with proc repr(t: typedesc): string = t.name
11:53:14VarriountJehan_: Also, part of the reason 1.type.repr fails also causes type(int) to fail
11:53:42Jehan_Ah, I see.
11:53:46VarriountJehan_: I don't have any use case in mind, other than preventing a compiler error and providing a more user-friendly experience.
11:55:20Jehan_Well, the above would give you an implementation for repr(), but doesn't fix the error with type(int).
11:56:13VarriountJehan_: Yes, but the above implementation is a userspace fix. Shouldn't this kind of fix be part of the compiler code?
11:56:14EXetoCaren't both the same typedesc?
11:56:32EXetoCnvm
11:56:51Jehan_I'd have to check, but in principle I think it could be stuffed in system.nim (yeah, I know).
11:57:20EXetoCint.type is typedesc[int]
11:57:39VarriountEXetoC: How do you know that?
11:58:21EXetoCVarriount: because I'm assuming that the error message when passing it to echo is correct
11:58:44EXetoCand, int.type is 1.type
11:59:06VarriountEXetoC: Try echo(type(int))
11:59:40EXetoCthat's what I meant. Error: type mismatch: got (typedesc[int])
12:00:10VarriountEXetoC: The error is erroneous
12:00:22EXetoCand echo(int.type is 1.type)?
12:01:06VarriountEXetoC: The compiler is only checking the 'int' part for some reason. If you change it to echo(type(int)), you get an internal error.
12:03:32EXetoCI tried that like I said; it prints true
12:04:20EXetoCehm
12:04:59EXetoCI was confusing the two. it gives me the error that I just showed you
12:05:34Jehan_The following seems to work: proc `type`(t: typedesc): typedesc = typedesc[t]
12:05:55Jehan_Not sure if overloading `type` like that doesn't break something else, though.
12:06:23VarriountJehan_: Again, it's a question of, should these things be in 'userspace', as part of the standard library, or 'compilerspace'?
12:06:56Jehan_Varriount: If it doesn't make a difference, I'm not sure it matters.
12:07:27Jehan_I'm more worried about overloading type or repr breaking something in a very subtle fashion.
12:07:38EXetoCJehan_: type(int) works for me as I said. can you show me what it is that fails?
12:08:15EXetoCJehan_: you could at least run the test suite. unfortunately it's hard to keep track of things since so many tests fail already
12:08:46Jehan_EXetoC: No idea, I was simply accepting that it broke.
12:09:06Jehan_And this is something where I wouldn't blindly rely on the test suite.
12:09:47Jehan_Hmm, "var t = int.type" does break, but that looks more like the type inference algorithm getting confused.
12:10:27Jehan_Speaking of which, "internal error: GetUniqueType" happens in a lot of places if you use templates.
12:10:46Jehan_Is it really an internal error or something that should be promoted to a proper error?
12:11:00EXetoCit does. testing things with echo is a little quirky
12:11:58Jehan_Almost everytime I've gotten it, it means that the compiler couldn't infer a type, and that's normally possible. But an internal error doesn't help you locating where things go wrong in your source code.
12:12:08VarriountAnyone know what GetUniqueType is actually supposed to do?
12:12:22*untitaker quit (Ping timeout: 245 seconds)
12:12:46EXetoCyeah and all internal errors are bugs
12:14:43Jehan_EXetoC: In theory, yes, but I'm wondering if that one actually is a bug.
12:14:59Jehan_As far as I can tell, it's hardly a "this can't happen" thing.
12:15:28EXetoCright
12:16:39Jehan_Well, it may be one in some subcases.
12:17:10Jehan_I'm looking at the code right now, and it seems to be something that can be both an internal error and a real error.
12:17:23Jehan_I suspect that reporting it as a real error would still be preferable.
12:17:39Jehan_Now to figure out how the compiler generates error reports … :)
12:18:01VarriountJehan_: As far as I can tell, parts of the C codegen use getUniqueType to get a C type
12:18:34Jehan_Varriount: Yup. As I said, it seems like it can be both.
12:18:37*untitaker joined #nimrod
12:24:35Jehan_Anyhow, I'll have to look at this later. See you around. :)
12:24:38*Jehan_ quit (Quit: Leaving)
12:31:36*darkf quit (Quit: Leaving)
12:44:54*boydgreenfield quit (Quit: boydgreenfield)
12:50:32NimBotnimrod-code/csources master 0a6e575 Dominik Picheta [+0 ±35 -0]: Rebuilt for powerpc at Araq/Nimrod@b3a39524eef
12:52:27NimBotAraq/Nimrod devel b386d38 Dominik Picheta [+0 ±1 -0]: Add asyncdispatch.unregister.
12:52:27NimBotAraq/Nimrod devel d54b902 Dominik Picheta [+0 ±1 -0]: Modified future behaviour when completing with an exception.... 3 more lines
12:52:27NimBotAraq/Nimrod devel b436636 Dominik Picheta [+0 ±1 -0]: Clean createVar template.
12:52:27NimBotAraq/Nimrod devel 225d4f4 Dominik Picheta [+0 ±1 -0]: Added powerpc to the list of CPUs that C sources are built for.
13:14:58*silven quit (Remote host closed the connection)
14:00:44*flaviu1 joined #nimrod
14:18:41*flaviu1 quit (Quit: Leaving.)
14:18:52*flaviu1 joined #nimrod
14:20:14*flaviu1 quit (Remote host closed the connection)
14:20:28*flaviu1 joined #nimrod
14:23:59*flaviu1 quit (Client Quit)
14:30:36*flaviu1 joined #nimrod
14:37:31*Varriount|Mobile quit (Read error: Connection reset by peer)
14:44:14*q66 joined #nimrod
14:44:27*q66 quit (Changing host)
14:44:27*q66 joined #nimrod
15:13:19*xenagi joined #nimrod
15:34:19*kunev joined #nimrod
15:35:12NimBotAraq/Nimrod devel f10f9c4 Varriount [+0 ±1 -0]: Update selectors.nim... 2 more lines
15:53:30*silven joined #nimrod
15:55:52VarriountAraq: ping
16:00:01*hoverbear joined #nimrod
16:14:57BitPuffinVarriount: it ain't gonna happen
16:19:50*caioariede quit (Ping timeout: 252 seconds)
16:20:24NimBotAraq/Nimrod devel 1d6c05e Varriount [+0 ±1 -0]: Update selectors.nim
16:30:10*caioariede joined #nimrod
16:34:47*wan quit (Quit: WeeChat 1.0-dev)
16:40:59Araqflaviu1: octal and hex parsing should also not raise overflows ... it makes no sense to use the same algorithm for all these
16:44:25*flaviu1 quit (Ping timeout: 276 seconds)
16:48:37AraqVarriount: the rename of considerAcc to considerAccent is poor, sorry
16:48:55Araqrename it to considerQuotedIdent
16:57:41*Jehan_ joined #nimrod
16:59:37AraqJehan_: getUniqueType computes a unique type so that tuple[a, b: int] and tuple[x,y: int] produce the same C struct
17:00:01Jehan_Araq: Yeah, I saw that part.
17:00:17Araqwe have no line info here so we bail out with an internal error
17:01:18Araqthe compiler used to prevent crazy things like 'var foo = int' but then zahary decided it's good to allow everything everywhere for some poor misguided C++ developer who wants to perform arbitrary computations on types
17:03:16Araqsame thing for "ptr void"
17:03:31Araqoh and proc (int, int)
17:03:46Jehan_I see.
17:04:13Jehan_Yeah, I was looking at how to figure out the line info and couldn't find any good way to do it.
17:17:12EXetoCAraq: it behaves like a normal var?
17:19:27EXetoCa typedesc var does indeed seem like a strange concept. are typedesc parameters different?
17:21:45*Demos_ joined #nimrod
17:23:16AraqEXetoC: it's a var of type typedesc[int] then
17:23:25Araqand shouldn't end up in the codegen
17:23:32Araqguess what ... it alsways does
17:26:15EXetoCok..
17:26:48EXetoCyeah but does it behave like one? assigning to one seems pointless
17:28:08Araqoh it's not check the manual for an example
17:28:20Araqit implements a typesafe printf
17:28:50Araqit's however a misfeature for all the people who confuse : and =
17:28:59Araqof which we have a lot
17:33:35*vendethiel quit (Quit: q+)
17:36:45EXetoCright
17:37:04EXetoCtype foo = ...?
17:42:05Araqyou're so inconsistent
17:42:29AraqI asked my mum and she doesn't know what "type" means
17:42:44EXetoC#_#
17:44:15EXetoCbut that depends on whether or not assignments should work in addition to initializations
17:44:35*ehaliewicz joined #nimrod
17:45:38*flaviu1 joined #nimrod
17:50:35flaviu1Araq: I disagree about it not making sense to use the same code for variable radix parsing, but other than that, the point of raising overflows is to let the compiler deal with it so that my code isn't obfuscated by overflow checking.
17:51:43*vendethiel joined #nimrod
17:52:27EXetoCok enough with the speculation. anyway, we're still not at 1.0 so fix the inconsistencies. just pull of the band-aid quickly :p
17:55:48*vendethiel quit (Client Quit)
17:59:51*silven quit (Remote host closed the connection)
18:02:07*silven joined #nimrod
18:08:56dom96Araq: Is 4K the optimal buf size? https://github.com/Araq/Nimrod/pull/1221
18:11:16Araqdom96: depends
18:11:42Araqit's just that an exact multiple of 4096 is pretty bad for the allocator
18:11:53Araqthat loses a full page due to alignment
18:12:05Araqif you don't use alloc it doesn't matter much
18:12:26dom96yeah, that's what I remembered.
18:16:36dom96Araq: Rewrite this using your fancy spawn: http://play.golang.org/p/RdbPXQcZHi
18:20:12Araqdom96: easy
18:20:27Araqand I don't have to use continuation passing style to do it
18:20:31dom96Good, we should add that code sample to the site
18:21:16*flaviu1 quit (Ping timeout: 276 seconds)
18:22:26dom96Is spawn ready for such code?
18:22:36Araqyes
18:22:45Araqwell I just renamed everything :P
18:22:48Araqbut yes
18:24:26dom96cool cool
18:46:03*kunev quit (Ping timeout: 252 seconds)
18:48:05Jehan_dom96: This example is pretty trivial even if you were to use raw POSIX threads.
18:49:07dom96I'm sure it is. Trivial examples make good showcases.
18:50:09Jehan_And I'm still struggling with the idea that Go managed to sell people on its extremely primitive channels as a novel concurrency model.
18:54:24Jehan_You could get 90% of the functionality in C++ by wrapping a deque in a mutex + condition variable. I.e., roughly five minutes of coding involved.
18:55:05vegaiJehan_: marketing.
18:55:37Jehan_vegai: You misspelled "snake oil". :)
18:57:07dom96I think that for most people it's not about the language, it's about the fact that Google made it and thus it must be great.
18:57:51Jehan_dom96: Then why isn't Dart getting more attention?
18:58:01vegaibecause Dart sucks while Go does not? :)
18:58:15Jehan_Eh, it doesn't?
18:58:37Jehan_It's not designed for the same use cases, of course.
18:58:37dom96Dart certainly gets attention.
18:58:56dom96Notch uses it for example
18:59:18Jehan_My point was that from a language design and implementation perspective, Dart is by far the more interesting and ambitious project.
18:59:25AraqJehan_: people think Clojure and Go will "easily run" on GPUs because of their "great" concurrency models
18:59:27EXetoCdom96: do you think nimrod_init in gtk2 is a good name? overloading init seems fine
18:59:44AraqEXetoC: please keep the name
18:59:55dom96EXetoC: It's fine, changing it now will break lots of code.
19:00:18Jehan_Araq: Well, Clojure actually does novel things.
19:00:37Jehan_I'm not a huge fan of LISP syntax, but that's personal preference.
19:01:00vegainovel things do not a successful language make
19:01:16AraqJehan_: like what?
19:01:35Jehan_vegai: True. But it means that the language is at least worth looking at.
19:02:23Jehan_Araq: Like trying to get STM to work. I don't think it'll work out in a meaningful way, but I may be wrong, and at least they're trying to push the envelope.
19:02:57Jehan_Whereas Go has a concurrency model that was outdated when Occam-2 was designed.
19:03:46Jehan_I wouldn't have a problem if Go, say, actually did CSP right. Simple is often good. But it doesn't even rise to that level.
19:04:45vegaimight it have been intended? Go isn't Rob Pike's first concurrent language after all
19:05:03vegaiI think Limbo had an identical mechanism
19:05:11Jehan_When you send a reference through a Go channel, the underlying object doesn't get copied.
19:05:12vegaiand then there was newsqueak
19:05:49Jehan_Which means that you're exposing yourself to race conditions, the exact thing you usually use channels to avoid.
19:06:21AraqJehan_: I argued with STM doesn't solve anything :P
19:06:24Araq*that
19:06:52Jehan_vegai: The problem isn't using channels to communicate. That's a fine model with many desirable properties. The problem is having a broken implementation of channels.
19:08:12Jehan_Araq: I don't necessarily disagree (and note that I've published a few papers on STM). That doesn't mean that I can be certain I'm right, which is why I happy that people keep experimenting with it even though I don't think it's currently workable.
19:10:31EXetoCdom96: ok but there are alternatives
19:10:33Jehan_I think that the Clojure people may be making a mistake by experimenting with a mix of way too many concurrency paradigms rather than picking one and perfecting it. But again, that's something that I can't be certain about.
19:11:12Matthias247I think that Go sucks while Dart is cool ;)
19:12:00Araqthe Clojure guys assume that a perfect shared memory GC is possible and built everything onto that. Incidentically they are right. :P
19:12:13Araq*upon that
19:12:46EXetoCdom96: remove, deprecate or keep forever
19:13:02Jehan_Araq: It's definitely possible. If you have the developer resources IBM has, that is. :)
19:13:32AraqOrionPK: your template system now works for me, let me push my fix
19:14:34Jehan_And you can get a pretty decent shared memory GC with much less if you aren't too demanding on your real time requirements.
19:17:03Jehan_Interesting, the Unity people are writing a CIL->C++ compiler.
19:17:33dom96EXetoC: just keep it
19:19:42Araqnow if only I could find the bug number ...
19:21:39BitPuffingo is fine it's just not really relevant
19:24:46NimBotAraq/Nimrod devel b230303 Araq [+3 ±1 -0]: fixes the bug that keeps the template engine package from working
19:24:46NimBotAraq/Nimrod devel 04a1555 Araq [+1 ±30 -1]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel
19:24:55*askatasuna joined #nimrod
19:32:42EXetoCdom96: not that it's an intrusive change, but ok..
19:33:00EXetoCnow to figure out how to expand the text view but not the input widget below
19:36:23*Kazimuth joined #nimrod
19:40:06EXetoChomogenous = false
19:40:44dom96what are you writing?
19:41:09EXetoCwho knows
19:43:43EXetoChave you thought some more about other widget engines? we should decide which one is worthy of a high level interface
19:44:52*ehaliewicz quit (Ping timeout: 245 seconds)
19:46:57*flaviu1 joined #nimrod
19:52:29flaviu1Araq: I agree that that patch wasn't very good, but do you have any idea why it worked when it shouldn't have?
19:53:09Araqno
19:53:16AraqI think you're wrong
19:53:37Araqand you had some old version of the compiler lying around or something
19:53:39*vendethiel joined #nimrod
19:54:11NimBotAraq/Nimrod devel ab5f227 Araq [+0 ±1 -0]: pdcurses wrapper compiles again
19:56:45flaviu1Araq: I just pulled the freshest version, it fails without that patch and succeeds with it.
19:58:03Araqflaviu1: what's the original diff again?
19:58:17AraqI mean the patch you applied to get `1/2` to work
19:59:05flaviu1Araq: https://github.com/flaviut/Nimrod/commit/a568c6102fdc29074ddd7309544c0487dfecb25c
20:01:01Araqah I see
20:01:15Araqif name[0] in 'a'..'z': might indeed trigger some unknown bug
20:01:28Araqif name[0] in {'a'..'z'}: shouldn't
20:02:03Araqbah, toLower
20:02:15Araqwhen you already know it's an upper cased letter
20:02:28Araqthe old version was much better
20:02:36Araqit teaches people how to program
20:03:05flaviu1Araq: Yeah, I overlooked that I could have just done toUpper instead of checking the range
20:04:12Araqwhat's wrong with c - 'a' + 'A' anyway, it's a natural solution
20:04:40Araqcould have masked the 7th bit instead
20:04:45flaviu1It isn't very readable and it also becomes obfuscated with the ords mixed in
20:04:49Araqthat would be obfuscation :P
20:05:16*Jehan_ quit (Quit: Leaving)
20:05:24flaviu1The compiler probably optimizes it down to that anyway
20:05:45Araqyeah sure
20:07:43Araqbtw don't you dare to use pegs in strutils, we try to avoid unnecessary dependencies
20:08:00Araqalso efficiency is a concern in a *standard* library
20:08:15Araqand yes. it is MORE important than "clean" code
20:09:30flaviu1Araq: Where did I mention pegs? I can't remember
20:09:41Araqin some commit message perhaps
20:12:34flaviu1Araq: I see; yes, that would probably be overkill unless pegs had an amazing optimizer
20:13:57Araqflaviu1: even it gains an amazing compile-time optimizer, the user pays for it with increased compile times
20:14:15Araqin the long run we'll get that and also compiler caching so that it doesn't matter
20:14:30Araqbut in the long run we're also all dead
20:15:06Araqhmm variations of
20:15:10Araqvar d = 'z'
20:15:11Araqecho d in 'a'..'z'
20:15:15Araqall work for me
20:18:48flaviu1Araq: What about `if d in 'a'..'z':`?
20:20:06Araqworks in an 'if' too
20:25:31flaviu1I've copied the methods out exactly, I can't reproduce it anywhere but in the compiler
20:27:31Araqcheck the generated C code please then
20:28:43caioariedehey guys, what's the best approach to inspect the content of a variable?
20:28:57EXetoCrepr?
20:29:18caioariedevar x: typedesc = int; echo(repr(x)) ?
20:30:00caioariedeI'm getting -- Error: internal error: GetUniqueType
20:30:06EXetoCdoesn't work with typedesc
20:30:18EXetoCsee typetraits.name
20:32:50flaviu1Araq: https://gist.github.com/flaviut/c34396eab67a83a99546
20:35:06Araqflaviu1: well it looks correct to me
20:35:08flaviu1The generated code looks fine
20:39:30Araqflaviu1: check out tslice475623's definition please
20:40:19flaviu1Araq: Its correct
20:40:31flaviu1but refresh the page anyway
20:42:25flaviu1Araq: I got it to reproduce
20:42:38*njoejoe` joined #nimrod
20:42:51Araqwell?
20:43:19flaviu1https://gist.github.com/flaviut/2d97efdc99ee97528ba7
20:43:49*njoejoe quit (Ping timeout: 240 seconds)
20:44:04flaviu1It works fine on 'auto', but it fails on 'Union'
20:44:27Demos_does it fail for union as well?
20:44:34flaviu1Demos_: Nope
20:44:42Demos_WTAF
20:44:54flaviu1If it starts uppercase, it gets lowecased somehow
20:45:05caioariedeI'm trying to use the module tables to store some generic values but I'm getting some errors. I'm missing something? -- https://gist.github.com/caioariede/9986786099eef53e093a
20:45:12flaviu1if its lowercase, it gets uppercased
20:46:07Araqflaviu1: well the code works as you wrote it
20:46:11flaviu1caioariede: ContextValue doesn't have a T
20:46:16flaviu1on line 16
20:46:33flaviu1err 17
20:46:35Araqyou check *name* and not *result* after all
20:46:49caioariedeit should be initTable[string, ContextValue[T]]() ?
20:47:38flaviu1caioariede: You can't get a T out of thin air, try TObject
20:48:21Araqflaviu1: your code with if name[0] in {'a'..'z'}: produces the same output
20:49:07flaviu1Araq: I really failed there :facepalm:
20:51:19flaviu1Wow, really sorry about that
20:51:36caioariedeflaviu1: yeah.. it worked, but then it's not generic anymore. Look, I updated the example: https://gist.github.com/caioariede/9986786099eef53e093a
20:52:22caioariedeI think I'm not in the right path, maybe I need to use something different than the tables module :(
20:52:39Araqflaviu1: don't worry, you can always blame the 1 letter variables or the fact that the 3 line implementation of 'mangleField' has no comments
20:52:48Araqsorry... I'm still pissed
20:53:29*xenagi quit (Quit: Leaving)
20:55:07flaviu1Araq: I've already stopped mentioning 1 letter variables, but that was really embarrassing. Really sorry for wasting your time
20:56:51Araqflaviu1: you didn't waste it, we found the bug quickly.
20:57:23EXetoC:p
20:57:48Araqannoying is that people blame me for their very own incompentence
20:58:10Araqsorry to be harsh, but in lots of respects nimrod pushes the state of the art
20:58:21Araqand all I get back is "ooh this in confusing"
20:58:34Araqand "ooh, I don't understand it, so it must be your fault"
20:59:18*bjz joined #nimrod
20:59:24Araqtake lambda lifting for example
20:59:31Araqyes the code IS really complex
20:59:41Araqthere have been books written about it though
20:59:56Araqmaybe it's an inherently complex problem then?
21:13:58flaviu1caioariede: You can't make something with variable sized elements
21:15:07flaviu1You could make it a table of pointers, although I think you would need some ugly casting
21:15:23caioariedeflaviu1: yeah.. I'm close to this
21:15:25caioariedehttps://gist.github.com/caioariede/9986786099eef53e093a
21:15:48EXetoCyou can have heterogenous types with fixed sizes. variants we call it
21:15:54caioariedeis it possible to store the type of the object?
21:15:59caioariedelook line 7
21:16:54caioariedefor example: ContextValue(value: "bar", kind: string) -- is it possible to store "string" in a field for later type casting?
21:17:31Araqcaioariede: what do you really want to achieve? a "context" is not really a meaningful name
21:18:00Araq(yeah the compiler uses it everywhere too, spare me)
21:18:10EXetoCcaioariede: http://build.nimrod-lang.org/docs/manual.html#object-variants
21:18:17flaviu1caioariede: http://build.nimrod-lang.org/docs/typeinfo.html , the compiler stores the type information already
21:18:30flaviu1but I'm not sure of practicality.
21:18:46Araqflaviu1: marshal.nim uses typeinfo
21:19:43caioariedeAraq: I'm trying to create a key-value dictionary where the values are from different types (int, string, objects, etc...)
21:20:10dom96Araq: What plans are there, if any, for making stack traces nicer when using macros?
21:20:19flaviu1caioariede: Are the types you need to support open-ended?
21:20:44flaviu1Ex, does client code need to be able to use types that haven't been already added?
21:20:50Araqdom96: well I am still not sure what the real problem is
21:20:51dom96caioariede: You could use the json module for this
21:20:59Araqdom96: I think it's simply a bug somewhere
21:21:42dom96Araq: There are possibly two different problems.
21:22:08dom96Araq: One is likely a bug, but the other is the repetition of 'cb' in the stack trace.
21:22:24flaviu1caioariede: https://gist.github.com/95b7b7cfcc318135e45f works, very ugly though
21:23:17dom96flaviu1: You shouldn't need a cast there
21:23:23dom96type conversion should suffice
21:23:42flaviu1variant types combined with the typeinfo module should get you want you want
21:24:00flaviu1dom96: Shouldn't and don't are different things :P
21:24:37caioariedeyeah... my only concern is that then, I'll need to know which types I'll need to cast to
21:25:39dom96I think using PJsonNode or creating something similar to it should be enough for your needs
21:27:41flaviu1dom96's suggestion is the best, you'll just end up reinventing PJsonNode otherwise
21:28:18caioariedeI'm looking to it, thank you guys.
21:29:44flaviu1Araq: Keep in mind that people don't tend to feel strongly enough about the things they like to mention it, but feel very strongly against things they don't like
21:34:19*bjz quit (Ping timeout: 240 seconds)
21:39:01caioariededom96: flaviu1: yeah.. PJsonNode doesn't fit my needs.. I need to store object references too, not just strings and integers :(
21:41:38dom96caioariede: Copy the implementation and add an ObjRef kind
21:42:28caioariededom96: look my current implementation: https://gist.github.com/caioariede/9986786099eef53e093a
21:42:38caioariedeis it possible to store the type of the value?
21:42:43caioariedefor example, kind: typedesc
21:42:57caioariedethen later I know to which type to cast
21:43:05dom96I don't think so
21:43:16dom96You can't store type descs at runtime IIRC
21:43:31EXetoCenumerators won't do?
21:46:35Araqwell you know ... TAny already exists, caioariede
21:46:55Araqwhich does what you're after
21:57:44flaviu1caioariede: I think the best you can do is throw an error when the client code gets the types wrong
22:00:34flaviu1It seems that the GC stores the type information in a way that isn't suitable for your purposes, maybe a macro that stores the type information a runtime as a hash?
22:01:11Araqor maybe read what the nimrod's creator has to say about this topic
22:01:29Araq"well you know ... TAny already exists, caioariede
22:01:33Araqwhich does what you're after"
22:02:15Araqnimrod has RTTI and TAny makes use of it
22:03:13flaviu1Araq: For my own use, is there any way to get some sort of unique identifier for a type at runtime?
22:04:22Araqsystem.getTypeInfo returns a pointer
22:04:52Araqsome people say you can cast a pointer to an 'int' and get an ID-like value
22:05:51caioariedeAraq: it worked quite well! :) https://gist.github.com/caioariede/9986786099eef53e093a
22:06:09caioariedeI can retrieve strings and ints using getString and getInt (after checking the type with akString and akInt)
22:06:22caioariedeis there a way to get an object? It seems there's no getObject proc
22:06:40flaviu1I thought that each object had its own copy of the TypeInfo, but its much more useful if its global.
22:07:53flaviu1Thanks
22:09:00Araqcaioariede: you can iterate over all the fields in an object with the API
22:09:46caioariedeis the getObject proc really missing or it's proposital?
22:12:27NimBotAraq/Nimrod devel 1d0175e Grzegorz Adam Hankiewicz [+0 ±2 -0]: Adds explicit titles to documentation index.
22:12:27NimBotAraq/Nimrod devel d33edd2 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds documentation sections to the index.
22:12:27NimBotAraq/Nimrod devel 400dd20 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Splits index into documents and APIs.
22:12:27NimBotAraq/Nimrod devel 5962119 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Moves TOC index entry generation to rstgen module.... 3 more lines
22:12:27NimBot20 more commits.
22:12:54Araqcaioariede: what should a getObject return?
22:13:38Araqwhat type should that object have then? keep in mind inheriting from TObject is optional
22:14:15caioariedek
22:14:51*ehaliewicz joined #nimrod
22:15:53OrionPKaraq it looks like some of my template code is working btw
22:16:02OrionPKjust the tests in the lib itself aren't working
22:16:14*ehaliewicz quit (Remote host closed the connection)
22:16:22AraqOrionPK: well look at my commit, I added your tests to the test suite
22:16:42OrionPKI havent even gotten latest yet, running off a couple weeks back I think
22:16:59Araqwell I fixed it today
22:17:16OrionPKgetting latest again
22:17:24OrionPKcool! good to hear
22:17:28Araqping Varriount
22:18:31OrionPKaraq yep, passed! thanks :)
22:18:54AraqOrionPK: well look at how I fixed it
22:19:01OrionPKIm going to work on a babel release as I have time
22:19:07OrionPKhmm?
22:19:13Araqa suprising oversight
22:19:15OrionPKwhich commit?
22:19:33Araqsimply forget to add 'tyChar' to the list of things that are kept in a VM register
22:19:37OrionPKwell, hopefully my tests help things stay robust as the vm evolves
22:19:37Araq*forgot
22:20:19OrionPKoops
22:33:52*Matthias247 quit (Read error: Connection reset by peer)
22:40:59*boydgreenfield joined #nimrod
22:44:54Araqgood night
22:46:34NimBotAraq/Nimrod new_spawn 030eac8 Araq [+0 ±7 -0]: bugfix: regionized pointers in a generic context; renamed 'Future' to 'Promise'
22:58:50*ehaliewicz joined #nimrod
22:59:49VarriountAraq: Any other issues that I could possibly fix?
23:03:06OrionPKhow does the delegator syntax work now?
23:04:15OrionPKnevermind..
23:21:57OrionPKdom96 https://github.com/nimrod-code/packages/pull/59
23:22:05*darkf joined #nimrod
23:22:08*superfunc joined #nimrod
23:22:20dom96OrionPK: Missing comma
23:23:34OrionPKdoh
23:24:14OrionPKadded
23:25:41NimBotnimrod-code/packages master de81fb7 onionhammer [+0 ±1 -0]: Added nimrod templates module
23:25:41NimBotnimrod-code/packages master ed49d1a onionhammer [+0 ±1 -0]: Fixed missing comma
23:25:41NimBotnimrod-code/packages master 4f55954 Dominik Picheta [+0 ±1 -0]: Merge pull request #59 from onionhammer/patch-2... 2 more lines
23:27:44OrionPKthanks