00:11:46 | * | Trixar_za is now known as Trix[a]r_za |
03:50:31 | * | Trix[a]r_za is now known as Trixar_za |
05:45:55 | * | Trixar_za is now known as Trix[a]r_za |
10:52:06 | * | filwit joined #nimrod |
10:53:23 | filwit | hi, Araq, I'm not sure you're around, but I was thinking about our last discussion on factory functions vs constructors |
10:54:04 | filwit | and I came to the conclusion that I like factory functions, except 'attached' to the Type itself |
10:54:28 | filwit | I'm not sure if there's currently a way to do this in Nimrod (i'm playing around trying to figure it out) |
10:54:37 | filwit | but what I mean is something like this: |
10:54:44 | filwit | type Foo = object |
10:54:48 | filwit | bar : uint |
10:55:27 | filwit | proc new(f:TypeOf(Foo)) : ref Foo = |
10:55:31 | filwit | result.new() |
10:55:37 | filwit | result.bar = 2345 |
10:55:47 | filwit | proc main = |
10:56:01 | filwit | var f = Foo.new() |
10:56:15 | filwit | echo f.bar # prints 2345 |
10:59:13 | filwit | this way I can see what Type i'm creating at a glance (which was my argument in favor of Constructors), but you still have the abstraction capabilities and factories, and consistency of a "one-proc-model-that-does-all" (which keeps the learning curve flat) |
11:00:22 | filwit | any naming conventions, eg, 'new', 'init', 'create', etc, will be easy to pick through with proper IDE suggest features, and easy to understand at a glance |
11:02:49 | filwit | So in short, I agree that factories are a better choice, and it would still be up to the library creator to write factories in the style or not |
11:05:32 | filwit | I think that having the ability to attach a Proc to a Type is a Win-Win situation, and an elegant middle ground |
11:05:57 | filwit | but please, let me know your thoughts :-) |
11:08:17 | filwit | If you don't have any technical or personal objections to the idea, I would like to try and implement it myself (though I'm not sure entirely how far I will get, at least not soon) |
11:10:53 | filwit | ....wow.... okay... probably should have tried it out a bit more before posting :) |
11:11:03 | filwit | turns out this already works if i do: |
11:11:21 | fowl | use type() instead of typeof() |
11:11:22 | filwit | proc new(f:Foo.type) : ref Foo = |
11:11:42 | filwit | fowl, ya. Just figured that out, thanks |
11:11:53 | filwit | soo.... that's sweet |
11:12:27 | filwit | guess I'll be using that for all of my construction functions |
11:17:03 | dom96 | hello everyone |
11:17:13 | filwit | hi dom96 |
11:17:27 | dom96 | hello filwit! |
11:17:49 | Araq | filwit: I read your suggestion |
11:17:52 | Araq | and I like it :-) |
11:18:01 | filwit | cool |
11:18:03 | filwit | :) |
11:18:08 | Araq | I will read it again this weekend though :P |
11:18:20 | Araq | thanks to NimBot these things are now logged :D |
11:18:29 | filwit | handy |
11:18:31 | Araq | I'm pretty busy with integer types btw |
11:18:42 | Araq | I've implemented my original idea |
11:18:58 | Araq | as the other solution produced bugs even in the compiler itself |
11:19:08 | filwit | what's happening with uint vs int? |
11:19:27 | fowl | nimrod 0.8.15 introducing int4 and int2? |
11:19:48 | Araq | I despise unsigned ints, but people moaned enough |
11:19:55 | Araq | so nimrod will get them |
11:20:06 | Araq | however, "uint64" is not an ordinal type |
11:20:27 | Araq | as then I'd have to use bignums in the compiler itself everywhere to model this properly |
11:20:43 | Araq | and that's too much work :P |
11:20:54 | Araq | plus I have no idea how compile times would be affected |
11:21:48 | Araq | see http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ for why Nimrod didn't include them |
11:21:50 | filwit | won't uint just a a 'distinct int'? |
11:21:58 | Araq | that's possible |
11:22:10 | Araq | but not that good for C compatibility |
11:22:17 | filwit | ah, i c |
11:22:53 | filwit | still, there shouldn't be a ton of problems since int/uint are the same size |
11:23:17 | filwit | I would think at least |
11:23:26 | Araq | there is no problem if you don't use the full range in the first place |
11:23:49 | Araq | if you need to care about all the edge cases + overflows it's quickly an enormous effort |
11:24:00 | Araq | it's a PITA in the compiler for instance |
11:24:09 | Araq | and yet I'm pretty sure bugs remain |
11:24:53 | Araq | if you use 'int' for speed and do some graphics/game programming where the range is less than -say- 1 Million |
11:25:15 | Araq | then you can be sloppy about these things |
11:25:42 | filwit | well, I'm not fully aware of the challenges of super-low-level stuff like that |
11:25:58 | filwit | but I'm sure you'll find a good solution :) |
11:26:14 | Araq | thanks |
11:26:30 | Araq | I think I found it; tests will tell today whether I was right :D |
11:26:55 | filwit | good luck! |
11:26:58 | Araq | it's quite advanced, the compiler figures 'and 0xff' fits in a byte ... |
11:28:07 | filwit | so uint can end up being a single byte? |
11:28:19 | Araq | basically it does interval arithmetic to be smarter |
11:28:29 | filwit | interesting |
11:28:35 | Araq | and allows any implicit conversion that does not lose any information |
11:28:56 | Araq | and requires explicit conversions for everything it can't prove correct |
11:29:37 | filwit | btw, that reminds me of an idea I had for strings once... where the compiler would choose a formatted string or regular string based on a weather the '$' symbol was present |
11:29:41 | filwit | so you could do: |
11:29:48 | filwit | var s = "My Name" |
11:29:57 | filwit | echo "Your name is $s" |
11:30:12 | filwit | and it would automatically format the string |
11:30:24 | filwit | anyways, just a random idea... |
11:30:32 | Araq | check the tests or examples for "interpolatedString" |
11:30:39 | Araq | it can be done with a macro |
11:30:40 | filwit | k |
11:30:52 | Araq | (with today's compiler) |
11:30:54 | filwit | oh, duh! |
11:31:14 | filwit | gah, Nimrod has the best macro system, I keep forgetting |
11:31:17 | filwit | one sec |
11:31:25 | Araq | well with 0.8.14 it worked :-) |
11:31:27 | Araq | we tested it |
11:32:42 | filwit | I'm not finding it |
11:32:48 | filwit | what folder is it in? |
11:36:31 | Araq | wait a sec ... |
11:38:16 | Araq | tests/run/tstringinterp.nim |
11:38:25 | filwit | kthanks |
11:38:27 | Araq | now that was easy .... ._. |
11:38:41 | Araq | make a proper stdlib module out of it please :-) |
11:39:17 | Araq | with a bit better names than concatStyleInterpolation and formatStyleInterpolation ... |
11:40:17 | filwit | you want it in strutils? |
11:41:01 | filwit | I was thinking it would be nice as a default for all strings (with a pragma to turn it for for compile time performance) |
11:41:16 | filwit | but that might be to big a change to make... |
11:41:20 | Araq | not in strutils please ;-) |
11:41:34 | Araq | it would make strutils depend on macros.nim ... |
11:41:47 | filwit | so system.nim then? |
11:41:53 | Araq | ha |
11:41:59 | Araq | that's even worse |
11:42:02 | filwit | lol |
11:42:09 | Araq | luckily the compiler will prevent it :P |
11:42:21 | Araq | as system.nim can't import anything |
11:42:22 | filwit | (thought that already imported macro.nim ;P) |
11:42:30 | filwit | okay I see |
11:42:40 | Araq | but you're right |
11:42:40 | filwit | so just a new lib then |
11:42:48 | Araq | people want it built-in |
11:42:53 | filwit | ya |
11:43:09 | Araq | the problem is that I don't as it's then useless for i18n |
11:43:18 | filwit | Google's Dart has this by default, though I don't know if it's optimized when the string doesn't have $ in it |
11:43:34 | filwit | il8n? |
11:43:41 | Araq | internationalization |
11:44:11 | filwit | isn't the '$' common among all keyboards? |
11:44:20 | Araq | in fact, arguably it should support the 'subexes' module ... |
11:44:24 | Araq | lol |
11:44:31 | Araq | I'm talking about $ on keyboards |
11:44:34 | Araq | *not* |
11:44:47 | Araq | I'm talking about: |
11:45:15 | Araq | echo "value is $x".translateToCurrentLocale |
11:45:49 | filwit | the formatting would happen before .translateToCurrentLocale |
11:45:57 | filwit | ? |
11:46:01 | Araq | yes |
11:46:09 | filwit | then what's the problem? |
11:46:13 | Araq | and that's wrong |
11:47:04 | Araq | "$x file[s] copied" --> becomes: $x & " file[s] copied" |
11:47:17 | Araq | ideally at compile time for efficiency |
11:47:34 | Araq | but you can't internationalize a bunch of string concatentations |
11:47:50 | Araq | you need to keep the pattern as a single piece |
11:48:02 | Araq | only then 'translate' can do it properly |
11:48:13 | filwit | ahh... i see the problem |
11:48:23 | filwit | hmm.... |
11:49:21 | filwit | ya that's impossible because if formating happens at compile-time and translate happens at runtime... it doesn't work |
11:49:29 | Araq | the problem is that if we do it by a built-in it's too opinionated |
11:50:02 | Araq | see 'subexes' for instance how IMHO *real* format strings can become |
11:50:38 | filwit | well... if "$x file[s] copied".translate() became --> ($x & " file[s] copied").translate() wouldn't that work? |
11:50:58 | Araq | no it wouldn't |
11:50:59 | filwit | maybe I don't see the problem... |
11:51:07 | filwit | anyways, for now I'll just make it a lib |
11:51:24 | Araq | translate could be a macro yes and see the & |
11:52:00 | filwit | ya, true |
11:52:17 | Araq | but that doesn't work too well |
11:52:30 | Araq | keep in mind that "file[s]" is already hackish |
11:52:50 | Araq | and you really want to use "file" or "files" depending on the value of 'x' |
11:53:31 | Araq | subexes include a conditional construct for this reason ... |
11:54:40 | filwit | okay, well how about "string".format() for the naming? |
11:55:38 | Araq | I dunno |
11:56:37 | Araq | make it useful as a raw string literal identifier |
11:56:38 | filwit | hmm... what about $"the string" |
11:56:50 | filwit | and put it in subex? |
11:56:51 | Araq | ambiguous |
11:57:00 | filwit | subexes** |
11:57:03 | Araq | putting it in subexes is fine |
11:57:14 | Araq | but $"the string" doesn't work |
11:57:25 | filwit | there's already a $string defined? what does it do? |
11:57:32 | Araq | as system.nim already has a `$`(x: string): string |
11:57:38 | Araq | it's a no-op |
11:57:50 | filwit | oh, right |
11:57:58 | Araq | in generic code you wanna say $x and get a string |
11:58:10 | Araq | no matter if it already is a string ... |
11:58:22 | Araq | it's really useful :-) |
11:58:31 | filwit | ya I agree |
11:58:39 | filwit | so, what's wrong with .format? |
11:58:52 | filwit | better idea? |
12:01:43 | Araq | echo format"${x +y}" |
12:01:51 | Araq | hrm, not sexy enough :P |
12:02:14 | Araq | and I think $$ is already taken by marshal.nim ... |
12:02:33 | Araq | plus an operator bites with 'echo' ... |
12:02:42 | filwit | format"..." describes what's happening though... |
12:03:03 | Araq | as 'echo $x' is parsed as '(echo) $ (x)' |
12:03:39 | Araq | format" ..." does not 'format' |
12:03:49 | Araq | that's what % does |
12:04:09 | Araq | format" ... " does a compiletime string interpolation with scope capturing ... |
12:04:33 | filwit | hmm.... okay |
12:04:59 | filwit | plus, if it's not an operator, people will just use "...", $x, "..." |
12:05:06 | filwit | when they can |
12:05:21 | Araq | well I don't mind |
12:05:22 | filwit | or '&' |
12:05:33 | Araq | all it does is saving some characters to type |
12:05:39 | filwit | what about $&"..." |
12:05:49 | Araq | that's good |
12:05:55 | Araq | I like it |
12:06:08 | filwit | kinda implies it's saving you from typing '&' all over the place |
12:06:16 | Araq | $ for "substitution" and & because it transforms into a concatenation |
12:06:19 | filwit | okay, I'll do that then |
12:06:34 | Araq | and then have $% for "formatStyleInterpolation" |
12:06:46 | filwit | okay |
12:06:47 | Araq | yummy |
12:07:47 | filwit | but I actually need to run for a minute, I'll do this when I get back |
12:14:35 | Araq | no problem |
12:28:11 | Araq | see you later |
12:47:48 | dom96 | Well that went far: Error: unknown processor: armv6l |
12:57:01 | filwit | okay |
12:57:11 | filwit | you working on arm stuff dom96? |
12:57:24 | dom96 | filwit: I got a Raspberry Pi yesterday :) |
12:57:34 | filwit | nice |
12:57:34 | dom96 | So I thought: Lets test Nimrod! |
12:57:40 | filwit | good |
12:57:59 | dom96 | I think all I need to do is add that CPU to niminst's config |
12:57:59 | filwit | how's the little system, I hear they're still selling like crazy |
12:58:16 | dom96 | Well it works :P |
12:58:22 | dom96 | And is quite cool. |
12:58:24 | filwit | :) |
12:58:31 | dom96 | Not that I have done anything interesting with it yet |
12:58:40 | filwit | what have you got installed on it? |
12:58:48 | filwit | Arch? |
12:58:51 | dom96 | yep |
12:58:54 | filwit | cool |
12:59:31 | filwit | what sort of software do they have built for Arch-ARM? I never could fine a repository... i'm assuming it's more like AUR |
13:00:09 | filwit | but I doubt they have Gimp and stuff right? |
13:00:38 | dom96 | Take a look here: http://archlinuxarm.org/packages |
13:00:54 | dom96 | So far everything that I attempted to install was there. |
13:01:08 | dom96 | I haven't installed anything "graphical" yet though |
13:01:11 | dom96 | just command line apps |
13:01:51 | filwit | cool, thanks for the link, I'll check it out in a sec |
13:05:06 | filwit | wow, looks like they have everything.... |
13:05:17 | filwit | Gimp, Inkscape, Gnome Shell |
13:05:32 | filwit | no Blender though |
13:05:32 | dom96 | indeed |
13:05:40 | dom96 | interesting |
13:05:40 | filwit | but that was expected |
13:07:51 | dom96 | why was it expected? |
13:08:32 | filwit | well I know Blender doesn't have an Android support yet, mostly because I don't think BlenderPlayer is fully ported to ARM yet |
13:08:38 | filwit | I follow BlenderNation.org |
13:09:13 | filwit | ARM graphics drivers are OpenGLES only I think, while Blender uses OpenGL |
13:10:36 | dom96 | oh |
13:16:40 | filwit | btw, dom96, it looks like your error is related to ARM6 architecture (a guess) |
13:16:56 | dom96 | yes, I know what the error is |
13:16:56 | filwit | but I thought ArchARM only ran on Arm5/Arm7 |
13:17:01 | filwit | oh, okay |
13:17:03 | dom96 | The csources are not generated for that architecture |
13:17:15 | filwit | ah |
13:17:19 | dom96 | It's an error from Nimrod :) |
13:21:04 | dom96 | I would love to play around with the GPIO pins. |
13:21:13 | dom96 | Looks like I'll be visiting a local electronics supplies store :P |
13:21:43 | filwit | no idea what GPIO pins are :-S |
13:23:03 | dom96 | They are pins which can be used for Input or Output and can be controlled by software/ |
13:23:08 | dom96 | They are available on the Pi. |
13:24:20 | filwit | oh cool, so you can make an app (in Nimrod of course) to control your garage door |
13:24:39 | dom96 | yep :P |
13:27:36 | filwit | do you know if Git branches are case sensitive? |
13:28:20 | filwit | nevermind i got it |
13:28:34 | dom96 | no clue |
13:42:52 | filwit | does Nimrod import folder names? |
13:43:20 | filwit | aka, dir: src/math/vectors.nim |
13:43:34 | filwit | dirc: src/math/matrix.nim |
13:43:42 | dom96 | Yeah, I think you can do "import "src/math/matrix.nim"" |
13:43:44 | filwit | import src.math |
13:43:52 | dom96 | You can't import a whole directory though |
13:44:15 | filwit | so I can't import all .nim files under a folder by just stopping at the folder? |
13:44:26 | filwit | or doing a '.*'? |
13:44:32 | dom96 | You could create a file and put in it all the imports |
13:44:36 | dom96 | and then just include it |
13:44:46 | filwit | okay, so it's like D then |
13:45:09 | filwit | I never did understand why you couldn't just import the whole folder like Java... but maybe there's a reason for it |
13:47:21 | dom96 | Seems like it could get confusing. |
13:47:28 | dom96 | If you forget what modules are in a folder. |
13:47:37 | dom96 | And what the modules contain... |
13:50:16 | filwit | idk, anytime you move code around, you have to change the imports |
13:50:33 | filwit | which is one benefit of using namespaces like C#/C++ |
13:50:52 | filwit | (though I prefer import/modules personally) |
14:04:08 | dom96 | I'm sure Araq can come up with a better reason than me :P |
14:04:37 | filwit | oh I'm just complaining for complaining sake really ;-P |
14:05:22 | dom96 | lol |
14:05:32 | filwit | I can't get this stupid thing to compile... urg |
14:05:49 | * | dom96 wonders if we could piggyback on the Raspberry Pi's popularity |
14:06:04 | dom96 | What's the problem? |
14:06:41 | filwit | well I'm copying the code from tests/run/tstringinterp.nim into lib/pure/subexes.nim |
14:07:08 | filwit | and renaming the functions concate/format to `$&`/`$%` |
14:07:34 | dom96 | right, and? |
14:07:45 | filwit | but while the test compiles and runs fine, my modified subexes is giving me a Internal Error: no string found |
14:07:54 | filwit | on this line: |
14:08:00 | filwit | macro `$&` *(e: expr): expr = |
14:08:08 | filwit | var args: seq[PNimrodNode] # THIS ONE |
14:08:20 | filwit | whoops, shit |
14:08:23 | filwit | wrong line |
14:08:27 | filwit | this one: |
14:08:42 | filwit | template ProcessInterpolations(e: expr) = |
14:08:43 | dom96 | Well an Internal Error means you've crashed the compiler... |
14:08:49 | filwit | var s = e[1].strVal #THIS ONE |
14:09:17 | filwit | ya that's what I'm guessing, but I'm not sure why i've crashed it |
14:09:22 | filwit | I'm importing the same things |
14:09:34 | filwit | it just doesn't like the line |
14:09:41 | filwit | var s = e[1].strVal |
14:09:41 | dom96 | gist all your code please |
14:09:51 | filwit | hmmm, k |
14:11:04 | filwit | https://gist.github.com/3066595 |
14:11:09 | filwit | errors on line 339 |
14:13:48 | dom96 | Are you using the latest compiler? |
14:14:16 | filwit | yes |
14:14:22 | filwit | just forked and built it |
14:14:26 | filwit | 0.8.15 |
14:15:05 | filwit | it's odd, cause it's working with the test, but not the subexes |
14:15:13 | filwit | ....but I have no idea why... |
14:15:19 | dom96 | Well it compiles for me. |
14:15:25 | filwit | what? |
14:15:29 | filwit | what does? |
14:15:34 | dom96 | The file |
14:15:42 | dom96 | You pasted |
14:15:49 | filwit | you replaced your subexes file? |
14:16:11 | dom96 | Well no. I just saved it as a different file |
14:16:26 | filwit | I made a test file, which imports subexes and uses the functions |
14:16:45 | dom96 | I see. |
14:16:53 | filwit | but I'm just copy pasting code from the tstringinterp.nim test which does compile and run |
14:16:54 | dom96 | ok, gist that too then :P |
14:16:58 | filwit | k |
14:18:17 | filwit | this doesn't work: |
14:18:18 | filwit | https://gist.github.com/3066618 |
14:18:42 | filwit | this does work: |
14:18:42 | filwit | https://gist.github.com/3066620 |
14:19:42 | filwit | the subexes file I'm importing in the first one (the one that doesn't work) is the modified subexes gist I paster originally |
14:20:28 | filwit | if you notice, the functions after ### --- TEMP --- ### in the subexes file are identical to the ones int the working test source |
14:20:41 | filwit | It's just copypasta |
14:22:12 | dom96 | hrm |
14:22:19 | filwit | ya... |
14:23:05 | dom96 | Working on it :) |
14:23:45 | dom96 | I'm pretty sure this is a bug. |
14:23:59 | filwit | That's what I'm thinking |
14:24:07 | filwit | I guess I'll wait till Araq gets back |
14:24:11 | dom96 | Some kind of difference between imported module processing and top level code processing |
14:24:23 | dom96 | You can try to fix it yourself if you want |
14:24:38 | dom96 | Bootstrap without -d:release and you'll get a stack trace |
14:24:49 | filwit | I'm not sure where to begin, it looks like a problem in the core expression tree structure |
14:25:03 | filwit | oh, okay |
14:25:38 | filwit | I'm actually getting a warning (as well as an error) about 'concat' being defined but never used |
14:25:47 | filwit | only in the subexes file thought |
14:25:50 | filwit | though** |
14:25:58 | filwit | in the working test, i don't get that warning |
14:26:09 | dom96 | I doubt that has any significance |
14:26:17 | filwit | ya didn't think it did |
14:26:29 | filwit | okay, i'll try bootstrapping in debug |
14:27:20 | filwit | what does 'koch' stand-for/mean anyways? |
14:27:27 | filwit | German maybe? |
14:27:32 | dom96 | It means cook in German :P |
14:27:44 | filwit | ah, thought it might be something like that |
14:29:59 | filwit | what is the order of the trace back? recent is last? |
14:30:25 | filwit | okay, never mind |
14:30:30 | filwit | just looking at it I can tell |
14:31:21 | filwit | looks like there's an assertion failure |
14:31:22 | dom96 | yeah |
14:31:36 | dom96 | The assertion is just so that it crashes and prints a stack trace |
14:31:57 | dom96 | evals.nim(1110) evalMagicOrCall |
14:32:04 | dom96 | That's where the error occurs |
14:32:36 | filwit | you following along with me, or something? |
14:33:00 | dom96 | nah, had the stack trace in another window, thought I'd help :P |
14:33:13 | filwit | lol, well thanks for the info |
14:34:05 | * | dom96 hopes his SD card won't die from all the writes and reads |
14:34:18 | dom96 | Any ideas on how many it can take? |
14:34:36 | dom96 | IIRC they are quite sensitive to many writes |
14:34:49 | filwit | no idea, sorry |
14:34:59 | filwit | buy backups :) |
14:35:19 | dom96 | The SD card I got cost me almost as much as the RPI heh. |
14:35:27 | dom96 | So I'm not buying any more :P |
14:35:50 | filwit | damn, really? |
14:35:54 | filwit | I thought those where cheap |
14:36:56 | filwit | I'ved that in places like South America, where the economy isn't as good as here, a copy of Windows is actually (quite a bit) more expensive than here |
14:36:59 | filwit | which is odd |
14:37:36 | dom96 | yay, Nimrod is compiling. |
14:37:45 | filwit | nice |
14:46:08 | dom96 | Nimrod Compiler Version 0.8.15 (2012-07-07) [Linux: armv6l] |
14:46:10 | dom96 | w00t |
14:47:27 | filwit | good work! |
14:47:37 | dom96 | :) |
14:47:42 | dom96 | It's quite slow. |
14:48:00 | dom96 | The CPU isn't the fastest though so I'm not surprised. |
14:48:04 | filwit | I imagine it's not the fastest machine in the world |
14:48:13 | dom96 | 700mhz :) |
14:48:37 | filwit | plus, Nimrod takes a less direct rout to compile code than... "normal" codegens |
14:49:31 | dom96 | Yeah, it goes through gcc. |
14:49:31 | filwit | I asked Araq if he ever had plans on making a LLVM backend, but he said it was impossible (or something along those lines) |
14:49:37 | filwit | I'm not sure why... |
14:49:49 | dom96 | I'm sure it's not impossible./ |
14:50:10 | dom96 | Well, maybe there are some features that Nimrod depends on that llvm would make hard to implement |
14:50:10 | filwit | ya, maybe he mis-understood what I was asking |
14:50:21 | filwit | like what? |
14:50:28 | dom96 | dunno. |
14:50:37 | dom96 | I'm clueless about LLVM :P |
14:51:01 | filwit | then how do you know LLVM would make it hard to implement :-V |
14:51:41 | filwit | anyways, I'm sure there's something |
14:51:58 | filwit | and it's not important ATM to have uber fast compilation times |
14:52:46 | filwit | it would be nice to eventually use GCC or LLVM directly, so there's no slow-downs on the parsing side |
14:53:24 | filwit | but if I remember correctly, most of the performance hit comes from the codegen anyways, so a slightly slower parser/lexer shouldn't make a huge difference |
14:54:43 | dom96 | GCC isn't that slow I don't think. |
14:55:05 | dom96 | And we can use tinycc instead :) |
14:56:05 | filwit | compared to LLVM, GCC is pretty slow |
14:56:15 | filwit | not horrible though |
14:56:23 | filwit | and ya, there are faster ones |
14:56:30 | filwit | though I've never used TCC |
14:56:56 | filwit | comparing GCC compile times to C# and DMD though... it's a big difference |
14:57:03 | filwit | when you have a lot of code |
14:57:17 | dom96 | We could also use clang. |
14:58:11 | filwit | ya, and like I said, I remember someone's statics before showing that the parser wasn't the big source of slow down |
14:58:20 | filwit | it's the codegen |
14:58:35 | filwit | and C compiles much faster than C++ |
14:59:06 | filwit | so parser Nimrod, then parsing C, before codegen probably isn't a big hit |
14:59:13 | filwit | compared to the codegen itself |
15:02:40 | dom96 | yeah |
15:03:10 | filwit | anyways, I'm going to head out for a bit |
15:03:21 | dom96 | alright. See you later |
15:03:28 | filwit | bye |
16:03:53 | * | Trix[a]r_za is now known as Trixar_za |
16:10:23 | * | Trixar_za is now known as Trix[a]r_za |
18:07:11 | * | XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.) |
18:19:02 | Araq | back |
18:19:26 | Araq | filwit: an internal error is a bug yeah ... I'll look into it next week or so ... |
18:19:44 | Araq | very busy with all the reported bugs and feature requests ... |
18:20:10 | Araq | and an LLVM backend is far from *impossible* |
18:20:35 | Araq | but it adds no significant value over the current approach |
18:20:54 | Araq | and maintaining one more backend is not a small task |
18:21:13 | Araq | we're talking about 5K lines of complex logic here |
18:52:56 | filwit | hi Araq |
18:53:29 | filwit | okay, I was trying to trace the error myself, but I got a bit lost as to what could be causing it |
18:53:41 | Araq | it's the 'concat' stuff I'm pretty sure |
18:53:52 | Araq | the warning makes the difference I think |
18:54:13 | filwit | hm.... |
18:54:38 | Araq | in fact ... macros still leak information |
18:54:51 | Araq | you can't just export them and expect things to work |
18:55:03 | filwit | I can gist the stack trace, maybe if you took a look at it you could give me a hint |
18:55:06 | Araq | the macro constructs a call to 'concat' so that needs to be exported too |
18:55:22 | Araq | alright stack trace helps |
18:56:10 | filwit | I did notice that evalAux om evals.nim only handles nkMacroStmt, and no nkMacroExpr |
18:56:15 | filwit | okay, one sec |
18:56:29 | Araq | there is no nkMacroExpr I think |
18:57:00 | filwit | https://gist.github.com/3066618 |
18:58:08 | Araq | oh |
18:58:09 | filwit | oh, I thought there was..., I thought it might have been and bug born from your work to merge stmt and expr |
18:58:35 | Araq | lol these internal errors are no bugs |
18:58:48 | Araq | they should simply be better error messages instead :P |
18:58:57 | filwit | I see |
18:59:04 | Araq | you attempt to get the string value out of a node that is no string literal |
19:00:03 | filwit | it's just odd that it works in an completely isolated case, but fails when it's part of an external lib |
19:00:26 | Araq | make it output 'renderTree(n)' in evals.nim:1110 |
19:00:42 | Araq | it's not that odd |
19:00:45 | filwit | k |
19:01:16 | Araq | as I said, the macro you use builds an AST that contains access to 'concat' which isn't exported |
19:01:47 | filwit | ohh... that' makes sense now |
19:01:55 | filwit | I thought that warning might be a clue |
19:02:33 | filwit | I could simply make that concat function and internal proc of both `$%` and `$&` |
19:02:46 | Araq | the macro should bind the symbol with a built-in API I think |
19:02:54 | Araq | but this API doesn't exist yet :-/ |
19:03:02 | Araq | so yeah you have to hack around |
19:03:03 | dom96 | haha, looks like i'm still a total noob at Nimrod :P |
19:03:22 | filwit | you and me both dom96 |
19:03:48 | filwit | (though you know a lot more than me :-P) |
19:04:01 | dom96 | Well at least you were correct to think that the warning was significant. |
19:05:58 | filwit | you're right! |
19:06:02 | filwit | it's official then |
19:06:15 | filwit | my Nimrod skillz r the gr8test |
19:06:46 | Araq | macros can easily be confusing ;-) |
19:06:56 | Araq | in fact, my plan is: |
19:07:01 | filwit | that concat proc was only used by `$&` |
19:07:08 | dom96 | Araq: Can I commit & push changes to get arm working? |
19:07:11 | filwit | but it's still not working... |
19:07:28 | Araq | 0.9.0 get integers and closures right |
19:07:36 | Araq | 0.9.2 get templates right |
19:07:43 | Araq | 0.9.4 get macros right |
19:08:03 | Araq | 0.9.6 .. 1.0.0 get term rewriting macros right ;-) |
19:08:41 | Araq | dom96: no ... |
19:08:47 | filwit | noble goals, but I hope that somewhere in there the aliasing issue between local variables and Types is addressed |
19:08:58 | filwit | that's my single biggest annoyance at this point... |
19:09:04 | dom96 | Araq: Why not? |
19:09:05 | Araq | show the diff please dom96 |
19:09:15 | filwit | since I'm a bit OCD and hate the whole TType/PType thing.... |
19:09:16 | dom96 | Fine, don't trust me! :P |
19:09:35 | dom96 | Araq: It's actually kind of weird. The CPU name is armv6l |
19:09:39 | dom96 | Not just 'arm' |
19:09:52 | Araq | filwit: I didn't list details like that :P |
19:10:07 | filwit | ahh, cool :-) |
19:10:18 | dom96 | So we will need to add it to platforms for each version I guess |
19:10:30 | Araq | and the TType PType thing is only annoying if you never used Delphi for years :P |
19:10:59 | dom96 | If someone manages to obtain different machines with differing ARM CPUs. |
19:11:08 | filwit | ya, never used Delphi at all... |
19:11:45 | Araq | dom96: the proper way is to adapt the build.sh script to detect any kind of ARM CPU |
19:11:57 | Araq | *not* make the compiler aware of this mess |
19:12:18 | dom96 | Araq: Right, how should it be done in platform.nim? |
19:12:38 | Araq | platform.nim already knows ARM I hope? |
19:14:22 | dom96 | yeah, but the name is 'arm' will it detect 'armv6l' as 'arm'? |
19:14:33 | dom96 | Well actually I know the answer to that. |
19:14:37 | dom96 | Because it complained. |
19:14:39 | dom96 | So it doesn't. |
19:15:53 | Araq | make build.sh convert armv6l -> arm ? |
19:16:21 | filwit | damn, well IDK what to do about this $%/$& thing... guess I'll just comment it out and put a #TODO on it |
19:16:42 | filwit | what's the preferred method to block comment? when false: |
19:16:43 | filwit | ? |
19:17:04 | dom96 | Araq: koch doesn't use build.sh how do you expect it to work? |
19:17:07 | filwit | or should I just remove it and do it again later since it's just copypasta to begin with |
19:17:39 | Araq | dom96: koch is built with nimrod ... |
19:18:02 | Araq | and "knows" the CPU it runs on as it's compiled into the koch executable |
19:18:08 | Araq | it all starts with build.sh ... |
19:18:13 | dom96 | Araq: ok. |
19:18:28 | Araq | filwit: whatever you feel like |
19:18:33 | filwit | k |
19:18:46 | Araq | what's OCD btw? |
19:18:59 | filwit | Obsessive Compulsive Disorder |
19:19:17 | Araq | and why can't you do 't: TType' like me? :P |
19:19:34 | filwit | I don't actually have OCD or anything... |
19:19:50 | filwit | i don't know how you can do TType stuff |
19:19:58 | filwit | it's crazy insane man |
19:20:29 | Araq | hey it's important whether it's value or a reference semantics |
19:20:57 | Araq | oh right ... you only want reference semantics everywhere right? :P |
19:21:04 | filwit | no |
19:21:14 | filwit | but I would like : type Foo = ref object |
19:21:24 | filwit | to _default_ to reference symantics |
19:21:31 | filwit | semantics** |
19:21:37 | Araq | ok |
19:21:42 | Araq | well no need to argue |
19:21:49 | Araq | the feature requests have been accepted |
19:21:53 | filwit | wasn't trying too :P |
19:22:01 | Araq | but still I wonder: |
19:22:26 | Araq | proc copy(dest: var TMyObject, src: TMyObject) = ... |
19:22:37 | Araq | is pretty common, right? |
19:22:44 | Araq | I mean to use 'dest' and 'src' |
19:22:49 | filwit | the real reason why I don't like TType/PType is because it's the only 'ugly' thing about Nim, and requires you to purposely mis-name all your types when there's a more elegant solution available |
19:23:08 | filwit | yes, that's common |
19:23:17 | Araq | and somehow nobody writes that as: |
19:23:27 | Araq | proc copy(destMyObject: var TMyObject, srcMyObject: TMyObject) = ... |
19:23:52 | Araq | so the type is not part of the name as soon as a "better" candidate is available ... |
19:24:00 | filwit | there's no need to stutter the type name |
19:24:24 | Araq | which implies you can use 1 letter parameter names for: |
19:24:35 | Araq | proc p(m: TMyObject) |
19:24:42 | Araq | and no information is lost ... |
19:24:49 | Araq | it's perfectly fine style IMHO |
19:24:55 | Araq | and once you do that |
19:25:09 | Araq | you can easily name your types without leading T and P ... |
19:25:39 | filwit | no, not really |
19:25:44 | filwit | but not because of parameters |
19:25:53 | filwit | because of local variables |
19:25:57 | filwit | i've tried |
19:26:11 | filwit | usually I'll write code like: |
19:26:17 | filwit | type Foo = object |
19:26:19 | filwit | ... |
19:26:23 | filwit | proc bar = |
19:26:31 | filwit | var foo : Foo |
19:26:38 | filwit | # whoops |
19:27:09 | Araq | var f: Foo |
19:27:14 | filwit | the problem is that IF I want to name my types without T/P, then I'm constantly running into conflicts |
19:27:47 | filwit | yes that works, and I could name it fooLocal, or fooo, or anything else |
19:28:06 | filwit | but I don't think forcing people to avoid naming conflicts is the best solution |
19:28:20 | filwit | it would be much more elegant if this simply worked |
19:28:50 | Araq | it's 3 lines in the compiler :P |
19:28:54 | Araq | I think |
19:29:06 | Araq | it will be weird for macros |
19:29:20 | filwit | 3 lines in the compiler? what is? |
19:29:34 | filwit | :-V |
19:29:52 | Araq | oh please, you simply need to make type name lookup prefer symbols of kind skType ... |
19:30:11 | filwit | I'm completely confused.... |
19:30:35 | Araq | I mean: implementing the feature you desparately want |
19:30:44 | Araq | takes like 3 lines in the compiler |
19:30:59 | filwit | oh, nice |
19:31:17 | filwit | why isn't it done yet then? hmmmmm?????!?! |
19:31:24 | filwit | :-P |
19:31:25 | Araq | lack of time? |
19:31:52 | filwit | well shit, if it's that simply, point me in the right direction |
19:32:04 | filwit | what file is this that only needs 3 lines of modification? |
19:33:22 | filwit | I feel horribly unproductive today, with my previous attempts to modify the compiler being thorted |
19:33:32 | Araq | semtypes.nim:187 |
19:33:39 | filwit | perfect, thanks! |
19:33:52 | Araq | you need to do a lookup that filters |
19:34:37 | Araq | oh hrm lookups.nim doesn't support that yet :P |
19:34:43 | Araq | so it's more than 3 lines |
19:34:49 | Araq | but trivial |
19:35:06 | filwit | I'll see what I can come up with |
19:35:36 | Araq | checkout proc SymTabGet*(tab: TSymTab, s: PIdent, filter: TSymKinds): PSym |
19:35:54 | filwit | k |
19:35:59 | Araq | lookups.nim needs a proc to access that proc |
19:39:04 | Araq | dom96: does -d:release work on ARM? |
19:40:04 | Araq | filwit: btw zahary did some tests recently |
19:40:27 | Araq | and Visual C++ produces a much faster Nimrod compiler than GCC, LLVM and even Intel C++ |
19:40:46 | Araq | it was 2.7s vs 3.2 vs 3.4 iirc |
19:41:05 | filwit | hmmm.. that's odd |
19:41:34 | Araq | which is one reason why I want to stick with the C code gen |
19:41:41 | filwit | I would like to see actual C++ examples being faster on VC++ than G++ |
19:42:05 | filwit | ya, the C codegen has some nice things |
19:42:38 | filwit | and like I said, parsing is probably a negligible cost compared to codegen |
19:43:02 | filwit | so it's not a big productivity issue really |
19:43:41 | Araq | I have some problems with the "parsing" vs "codegen" distinction :P |
19:44:09 | Araq | it's really "lexing" -> "parsing" -> "semantic checking" -> "code generation" |
19:44:10 | filwit | :-) |
19:44:26 | Araq | and "semantic checking" *is* expensive |
19:44:43 | Araq | often moreso than code gen |
19:44:59 | filwit | hmmm... well good to know |
19:45:10 | Araq | but somehow people don't even mention it :P |
19:46:53 | Araq | btw Nimrod executes the C compiler in parallel to keep all your cores busy |
19:47:21 | Araq | but the Nimrod compiler itself can't be parallelized easily |
19:47:28 | filwit | nice, I noticed Nimrod compiles pretty fast with the nimcache and stuff |
19:47:59 | Araq | you should try --symbolFiles:on but it's still buggy |
19:48:26 | filwit | well I'll avoid it for the moment then |
19:48:36 | filwit | sounds cool though |
19:48:57 | Araq | but recompile times of 0.1s are nice :P |
19:49:30 | filwit | nice |
19:49:32 | filwit | heh, I was thinking about proc parameters the yesterday, and I had a thought I'd like your opinion on (seeing as you know a ton about this stuff) |
19:49:48 | filwit | (this isn't a feature suggestion, btw, just random thoughts) |
19:50:18 | filwit | so basically, what if you had "typeless" parameter that looked like weak typed programming |
19:50:19 | filwit | so: |
19:50:33 | filwit | proc foo(x, y) = |
19:50:41 | filwit | x.doSomething() |
19:50:57 | filwit | var a : int |
19:51:00 | filwit | a + y |
19:51:11 | Araq | zahary already implemented that, but I don't know the status |
19:51:17 | filwit | then, the compiler would simply duck-type the "typeless" params are compile time |
19:51:23 | Araq | yep |
19:51:25 | filwit | really? |
19:51:28 | filwit | that's awesome |
19:51:32 | Araq | we know clay ;-) |
19:51:47 | filwit | well I don't, I came up with this independently |
19:51:50 | filwit | :) |
19:52:09 | Araq | I also want: |
19:52:16 | filwit | that's cool though, glad to here that Nimrod will be doing something like this |
19:52:30 | Araq | proc foo(x: int; y, z; a: bool) |
19:52:40 | Araq | note the ; |
19:52:49 | filwit | ya I was just going to ask about the syntax of that issue |
19:52:49 | Araq | so that some are inferred and some are not |
19:53:24 | filwit | cool :) |
19:54:28 | filwit | the ';' could be always used as a general 'end expr' symbol |
19:54:32 | filwit | var a, b : int |
19:54:38 | Araq | yep, planned |
19:54:39 | filwit | a = 1; b = 3 |
19:54:46 | filwit | cool :) |
19:54:47 | Araq | yes yes |
19:54:54 | Araq | your proc indentation feature is also easy to do |
19:55:10 | Araq | only needs changes to parser.nim |
19:55:22 | filwit | well I'm still struggling with the first problem :P |
19:55:23 | Araq | and yes it'd be nice if you could help with that |
19:55:44 | filwit | yes, I would like to be able to help out with compiler stuff |
19:55:52 | filwit | it's just a bit... complex, atm |
19:56:06 | filwit | though everything seems organized well so far |
19:56:15 | Araq | it isn't |
19:56:23 | Araq | but still bearable |
19:57:15 | filwit | well, once I change the symbol resolution issue, maybe refactoring some of the code is in order? |
19:57:18 | filwit | :-) |
19:57:24 | Araq | no please don't |
19:57:29 | filwit | damnit... |
19:57:56 | Araq | I hate it when I don't know where to find my code ... |
19:58:12 | Araq | that's far worse for my productivity |
19:58:39 | filwit | okay, I feel ya, what If I just went thought and changed a bunch of TType/PType things? |
19:58:54 | filwit | <8-D |
19:59:03 | Araq | I see |
19:59:06 | filwit | LOL |
19:59:15 | Araq | yeah I got the joke :P |
20:00:46 | dom96 | Araq: I don't think it does, however I tested it when I didn't yet edit platform.nim. I will try it again. |
20:01:03 | filwit | man I can't type today... I keep looking back and realizing I've typed things like *thought instead of *through |
20:03:22 | Araq | "It's been part of DMD2 for a while now. It allows you to do things like: |
20:03:24 | Araq | ubyte lowbits(int x) |
20:03:25 | Araq | { |
20:03:27 | Araq | return x & 7; |
20:03:29 | Araq | } |
20:03:30 | Araq | without an explicit cast. The compiler knows that x&7 can safely fit |
20:03:32 | Araq | inside a single byte." |
20:03:33 | Araq | argh! |
20:03:35 | Araq | D already does it |
20:03:36 | Araq | damn you, D ... |
20:03:52 | Araq | I thought Nimrod will be original with this feature ... |
20:05:13 | filwit | lol, nothing wrong with being second |
20:05:20 | filwit | there's only so many ideas in the world |
20:08:05 | Araq | oh well |
20:08:30 | Araq | at least I am smart enough to notice that bitwise or does not adhere to simple interval arithmetic rules |
20:08:37 | dom96 | pff. D. Nimrod's syntax is so much better. |
20:08:49 | dom96 | D doesn't stand a chance. |
20:10:14 | Araq | and both have no chance against Rust ;-) |
20:10:49 | filwit | I didn't like Rust for some reason... I forgot why though |
20:11:31 | filwit | ah, right.. pointer and namespace symbols like '->' and '::' |
20:11:38 | dom96 | Araq: Have some faith. |
20:11:41 | filwit | was one reason |
20:12:03 | Araq | faith? against a paid team of compiler devs? |
20:12:05 | dom96 | However I must admit, it does not look good. |
20:12:27 | filwit | does Rust even have meta programming? |
20:12:31 | filwit | what's that like? |
20:12:32 | Araq | which are not as brain dead as to leave out generics from their language? |
20:12:56 | Araq | afaik Rust's metaprogramming is not advanced yet |
20:13:09 | filwit | why would you want Generics when you have proper Templates? |
20:13:10 | Araq | and requires macro invokation with '#' |
20:13:31 | filwit | someone on the D forums figured out how you can even inherit from template functions |
20:13:46 | filwit | which was the only pro to Generics, If I remember correctly |
20:13:55 | dom96 | Araq: I saw their roadmap just today. Maybe I shouldn't show you it, might depress you. |
20:14:17 | Araq | filwit: I'm talking about the mystical "average programmer" |
20:14:50 | Araq | generics vs. templates is a lost argument for these as they don't care about the difference |
20:14:55 | filwit | ah.. that fabled creator is only myth and legend ;) |
20:15:17 | Araq | dom96: show me the roadmap please |
20:15:25 | dom96 | https://github.com/mozilla/rust/wiki/Note-development-roadmap |
20:26:01 | Araq | interesting |
20:26:15 | Araq | and they don't even list the features we have planned :P |
20:27:07 | dom96 | It's really unfair that they have mozilla backing them. |
20:27:46 | dom96 | btw filwit any progress on that Nimrod logo mockup? |
20:28:02 | filwit | honestly, I think their syntax is a bit confusing |
20:28:24 | filwit | dom96, no, haven't worked on anything Nimrod related in awhile |
20:28:29 | filwit | but I'll complete it |
20:28:35 | dom96 | Great :D |
20:28:45 | dom96 | I haven't actually used Rust, D, or Go. |
20:29:09 | dom96 | Ever since I found Nimrod I've been using it, heh. |
20:29:46 | filwit | I've used D and played with Go a few times |
20:29:56 | filwit | not a fan of Go, but D has some great things |
20:30:02 | filwit | most of which Nimrod has |
20:30:09 | filwit | and does better, IMO |
20:30:20 | dom96 | The C-like syntax really pushes me away from those languages. |
20:30:20 | Araq | ha thanks |
20:30:47 | filwit | the fact that there's no distinctions between Macro/Template/Proc use is something I think is really great about Nim |
20:31:10 | filwit | cause reading through code, all you're doing is tracing "function" calls, like in C |
20:31:18 | filwit | it's just easy to read and understand |
20:32:04 | filwit | (which is why I'm so against TType/PType stuff, not to bring that up again) |
20:32:21 | filwit | looking through Rust, it looks like it's got a lot of power |
20:32:33 | filwit | but I'd rather use D (between the two) |
20:32:43 | filwit | because D is easier on the eyes |
20:32:58 | filwit | though Rust's pattern matching is interesting |
20:33:45 | filwit | dom96: I'm fine with the C like {} syntax |
20:34:02 | filwit | but one thing I really like about Nimrod is it's case-insensitivity |
20:34:18 | dom96 | The reason Nimrod caught my eye in the first place is its python-like syntax. |
20:34:40 | dom96 | Back then I was really into and I just wanted a python which compiled to C. |
20:34:45 | filwit | notice on the roadmap their talking about universalizing the capitalization between old and new libs |
20:34:46 | dom96 | *into python |
20:35:09 | filwit | see, the Python syntax had the opposite effect on me |
20:35:22 | filwit | I almost passed Nimrod up completely after seeing a code example |
20:35:34 | filwit | but the feature list on the home page kept me reading |
20:35:34 | Araq | what? |
20:35:55 | Araq | you actually like nimrod's case insensitivity? |
20:36:01 | Araq | interesting :-) |
20:36:18 | filwit | ya, and the fact that '_' is just their for fluff |
20:36:30 | filwit | it means I can use other's libs in the style I want |
20:36:33 | filwit | which I like |
20:36:43 | Araq | well that was the point :-) |
20:37:08 | Araq | but would I do it again? |
20:37:14 | Araq | unlikely ;-) |
20:37:20 | filwit | lot of problems? |
20:37:27 | Araq | I would make the compiler enforce the naming convention instead |
20:37:33 | filwit | it obviously wont work with linking to C and such |
20:37:42 | dom96 | haha. |
20:37:44 | filwit | lol |
20:37:48 | dom96 | That would certainly make people angry. |
20:37:51 | filwit | all or nothing eh |
20:37:56 | Araq | in fact there are suprisingly little problems with C libs |
20:38:06 | Araq | and Nimrod's case insensitivity |
20:38:19 | Araq | I was suprised how few clashes it produces :D |
20:38:34 | Araq | no, I still like the insensitivity way |
20:38:48 | Araq | the reason why I would do it differently has to do with *people* :P |
20:38:48 | filwit | yes, I'm glad you didn't enforce a standard |
20:39:12 | Araq | because many people really dislike it |
20:39:15 | filwit | cause if it was foo_bar() I probably wouldn't have read any further :P |
20:39:39 | filwit | really? others don't like the case insensitivity? |
20:39:52 | Araq | yeah |
20:39:55 | Araq | many dislike it |
20:39:55 | filwit | I told my brother about it, and he was against the idea... but he usually is |
20:40:02 | dom96 | It's always the first thing they complain about |
20:40:03 | filwit | mostly because he does this: |
20:40:08 | filwit | class Foo { |
20:40:22 | filwit | private in bar; |
20:40:31 | filwit | public int bar() {...} |
20:40:32 | filwit | } |
20:40:38 | filwit | shit |
20:40:41 | filwit | should be: |
20:40:48 | filwit | public int Bar() { ...} |
20:41:12 | filwit | basically all public members are capitalized (C#), and privates are lower camelCase |
20:41:33 | Araq | privates are _thisWay in C# :P |
20:41:41 | filwit | usually, I know |
20:41:57 | filwit | but we don't do that in our SDK |
20:41:57 | Araq | public Foo Foo { get; set; } |
20:42:19 | Araq | C#'s style guidelines don't make any sense anyway |
20:42:36 | filwit | meh, I like them well enough |
20:42:38 | Araq | public Foo Foo { get; set; } // doesn't compile |
20:43:26 | filwit | ya, I was always torn between PascalCase and camelCase |
20:43:56 | filwit | in one way, PascalCase is more consistent, but in other camelCase has nice distinction between types/locals |
20:43:59 | dom96 | TIL that's called PascalCase |
20:44:29 | filwit | I usually use camelCase, but Reign SDK is PascalCase, so I'm use to both |
20:45:05 | filwit | I usually just use whatever the language recommends |
20:45:12 | Araq | at work I "program" quite some SQL :-) |
20:45:31 | Araq | it's soooo convenient to not have to care about this crap in a REPL |
20:45:46 | filwit | except in the case of Nimrod, where I just complain about every feature until you agree to do it just to shut me up |
20:45:59 | filwit | ;D |
20:46:44 | Araq | I don't mind :P |
20:47:46 | Araq | as I know time also deals with these things; nobody moans about time_t in C :P |
20:48:12 | Araq | time_t is from the gods and if you don't like it it's *your* problem |
20:48:23 | Araq | in fact |
20:48:41 | Araq | everything in C is the *programmer's* fault XD |
20:48:48 | filwit | lol |
20:49:15 | filwit | people don't complain about C, because to start down that path is to enter insanity |
20:49:38 | Araq | people worship C and UNIX |
20:49:46 | filwit | I know |
20:50:13 | dom96 | and vim |
20:50:24 | dom96 | Don't forget about vim :P |
20:50:41 | Araq | no! emacs! |
20:50:49 | filwit | okay, I understand how C is popular, but I never understood Vim's keyboard shortcuts |
20:50:59 | filwit | 'h' as up? |
20:51:06 | dom96 | What you mean that OS? |
20:51:06 | filwit | and 'l' and down? |
20:51:26 | dom96 | I can run quake in my emacs, it's obviously far better than vim! |
20:51:27 | filwit | but granted, I haven't given Vim much time of day |
20:52:11 | Araq | well every other widget in the OS uses the common cursor keys |
20:52:12 | dom96 | yes, why make arrow keys work when you can use letters to move the cursor! |
20:52:27 | Araq | so it's unproductive to learn Vim |
20:52:39 | dom96 | They could have at least used something like WASD |
20:52:55 | Araq | dom96: 'W' didn't exist back then |
20:53:05 | Araq | the letter 'W' was invented much later ... |
20:53:25 | dom96 | oh, did the ancient Mayans invent vim? |
20:53:38 | Araq | yep :P |
20:53:49 | filwit | that explains it |
20:54:44 | dom96 | Some poor calendar maker must have forgotten how to move the cursor and just gave up on finishing the calendar. |
20:55:11 | filwit | the mystery is solved |
20:55:46 | filwit | maybe at the end of the year, all Vim software will spontaneously erase itself |
20:56:00 | dom96 | That would be great. lol. |
20:56:12 | filwit | and all the Vim folks will end their lives thinking it's the end of the world |
20:58:29 | filwit | looks like they found the Higgs boson |
20:58:38 | Araq | yeah |
20:58:47 | Araq | unfortunately |
20:58:57 | filwit | you had a better theory? |
20:58:57 | Araq | I'd have preferred if they hadn't found it |
20:59:00 | dom96 | Not sure what benefit that really brings. |
20:59:02 | filwit | lol |
20:59:03 | Araq | lol no |
20:59:19 | dom96 | He wanted to find it himself. |
20:59:21 | Araq | but the standard theory is so ugly |
20:59:39 | dom96 | Using the Nimrod hadron collider simulator. |
20:59:42 | Araq | it'd be nicer if something would prove it wrong |
21:00:05 | Araq | http://www.osnews.com/story/25556 btw still my favourite |
21:00:14 | filwit | dom96: no one knows yet, but considering the research into quantum physics years ago now enables our computers today... I would say it's pretty cool |
21:00:47 | filwit | Araq: I don't really know all that math jumbo... |
21:01:18 | filwit | new standard theory: |
21:01:35 | filwit | proc main : {.magic.} |
21:02:02 | Araq | "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things," Landley explains, "It stopped making any sense before Linux was ever invented, for multiple reasons." XD |
21:18:53 | * | XAMPP joined #nimrod |
21:22:11 | dom96 | Araq: Do you know much about the longevity of SD cards? |
21:22:27 | Araq | SSD? |
21:23:36 | dom96 | No. Secure Digital: http://en.wikipedia.org/wiki/Secure_Digital |
21:26:41 | Araq | I dunno |
21:26:49 | Araq | I would be careful with it ;-) |
21:27:22 | Araq | as I've seen quite some SSD break when you're doing many writes |
21:27:53 | Araq | SSD sounds similar to SD so it should be similar for these :-) |
21:28:15 | Araq | that doesn't really make much sense |
21:28:32 | Araq | but it's interesting to notice how one's own brain "works" |
21:29:20 | dom96 | hrm? What doesn't make sense? |
21:30:35 | Araq | read it again |
21:36:33 | dom96 | i see. Well they are quite similar. |
21:36:38 | dom96 | Both use flash storage. |
21:36:52 | Araq | yeah I noticed that later too |
21:36:55 | * | Trix[a]r_za is now known as Trixar_za |
21:45:15 | Trixar_za | filwit really does have a one track mind, hey? |
21:46:11 | filwit | eh? |
21:46:27 | Trixar_za | The last 3 times I've seen you talk, it's been about factories |
21:46:28 | Trixar_za | :P |
21:46:41 | Trixar_za | And how they're superior |
21:46:53 | filwit | oh, lol |
21:47:03 | filwit | I was actually arguing in favor of Constructors before |
21:47:17 | filwit | but yes, it's been an on-going discussion |
21:47:25 | Trixar_za | lol, shows you how I have half-read stuff :P |
21:47:28 | Araq | I was arguing in favor of factories |
21:47:43 | Araq | though I don't really like them XD |
21:47:52 | filwit | now I'm in favor of Factories (applied to Types) |
21:47:59 | Trixar_za | Clearly I side with Araq - mostly because he has the cookies |
21:48:04 | filwit | so, var foo = Foo.new(...) |
21:48:21 | dom96 | Araq has cookies? |
21:48:27 | filwit | oh, well that's understandable... because of the cookies |
21:48:31 | Araq | if you need a factory, you want to abstract a type hierachy away |
21:48:35 | dom96 | How do I not know of this!? |
21:48:46 | Araq | which leads to the question: |
21:48:57 | Araq | why have the type hierachy at all in the first place? |
21:49:07 | Araq | use a sum type instead |
21:49:20 | Araq | however, unfortunately; it can't always be avoided |
21:49:42 | filwit | I think type hierarchy is logical |
21:49:50 | filwit | we sort of classify things that way naturally |
21:50:00 | filwit | but idk, whatever works best |
21:50:17 | Araq | hierarchies suck IMO ;-) |
21:50:31 | Araq | System.IO.Text.FileReader |
21:50:44 | Trixar_za | Ah, I was just about to ask if it has to do with that |
21:50:47 | Trixar_za | :P |
21:50:54 | filwit | what's wrong with that? |
21:51:00 | Araq | System.Properties.Settings.Argh |
21:51:10 | Araq | it's arbitrary |
21:51:13 | filwit | at least you know where things are coming from |
21:51:16 | Araq | that's wrong with it |
21:51:27 | Araq | it's bureaucratic too |
21:51:38 | Trixar_za | Like with python: self.wrap(string.str()).split() |
21:51:41 | Araq | why not Universe.System.IO? |
21:51:48 | Araq | why not Multiverse.Universe.System.IO? |
21:51:53 | filwit | because we program on computers? |
21:51:58 | filwit | and not universes |
21:52:04 | Araq | why not Settings.Properties? |
21:52:13 | Araq | what's the difference between them anyway? |
21:52:19 | filwit | that's acceptable |
21:52:32 | Trixar_za | oh right and don't forget self.wrap(string.str()).time.sleep(10) |
21:52:48 | filwit | I'm just in favor of understanding over abbreviation |
21:53:09 | Trixar_za | Actually that's all bad examples from me ;P |
21:53:13 | filwit | if I can't understand where things are coming from, it's hard to understand the structure... unless I wrote it to begin with |
21:53:31 | Araq | it's all coming from .NET :P |
21:53:32 | filwit | that's why hierarchy classification is, IMO, good |
21:54:36 | Trixar_za | md5sum = hashlib.md5(title+desc).hexdigest() |
21:54:42 | Trixar_za | ^--- real life example |
21:56:10 | Trixar_za | Well, made a little pretty of course |
21:56:17 | Trixar_za | Otherwise it will be one hell of a long line |
21:57:01 | dom96 | You can import things from directories in Nimrod can't you? i.e. import "Package/module" |
21:57:07 | dom96 | As long as that is possible I am happy. |
21:57:55 | dom96 | Because if you have large libraries you want to have modules with name like 'types.nim' |
21:58:12 | dom96 | and if you want to use multiple libraries these would clash without putting them into their own dirs. |
21:58:36 | dom96 | Well I guess you could always just name them: LibraryTypes.nim |
21:59:07 | Trixar_za | md5sum = hashlib.md5(((item.title+item.description).strip("Live Scores: ").replace("#", "")).encode("utf-8")).hexdigest() |
21:59:10 | Trixar_za | I was bored |
21:59:22 | Trixar_za | This is why you shouldn't write one liners in Python |
21:59:22 | Trixar_za | :P |
22:00:03 | dom96 | Trixar_za: Were you trying to obfuscate your code at the same time as writing it? |
22:00:47 | Trixar_za | Actually I'm using the md5sum to keep track of the rss feeds the bot has shown |
22:00:51 | Trixar_za | Doesn't always work |
22:01:03 | Trixar_za | Mostly because python's hashlib sucks by design |
22:01:42 | Trixar_za | feedparser rocks though |
22:04:21 | Trixar_za | Which reminds me, how does error handling work in Nimrod? |
22:05:02 | Araq | exceptions or return values |
22:05:15 | Araq | mostly exceptions |
22:05:34 | Araq | but thanks to 'discard' return values are possible too |
22:10:19 | Trixar_za | Oh yeah, discard :P |
22:11:01 | filwit | is there a reason you set things to nil in Nimrod on initialization? |
22:11:07 | filwit | var ident: PIdent = nil |
22:11:19 | filwit | isn't it defaultly nil? |
22:12:27 | Araq | yeah I'm just more explicit sometimes |
22:12:35 | filwit | okay, just woundering |
22:12:38 | filwit | wondering** |
22:12:44 | Araq | plus most of the code has been translated from Delphi :P |
22:12:57 | Araq | and Delphi has no implicit initialization |
22:12:58 | filwit | it was originally written in Delphi? |
22:13:04 | Araq | yeah |
22:13:13 | filwit | interesting |
22:13:24 | Araq | well ... the common subset of Delphi and Nimrod, in fact |
22:13:36 | dom96 | I thought it was pascal? |
22:13:46 | dom96 | Is there a big difference between the two? |
22:13:47 | Araq | there is no meaningful difference, dom96 |
22:13:51 | dom96 | i see |
22:16:40 | Araq | Trixar_za: http://www.youtube.com/watch?v=feAlOzra7LQ&feature=related |
22:18:41 | Trixar_za | One Nipple "AhAhAh" |
22:20:52 | filwit | reminds me of Dave Chappelle, lol |
22:20:57 | filwit | http://www.youtube.com/watch?v=xCbU_11hx8Y |
22:23:03 | Trixar_za | Mind you, I forgot about the Japanese version of Dragonball featuring Goku finding out the Bulma lacks a penis and balls |
22:23:35 | Trixar_za | Clearly the Americans can't deal with jokes like that |
22:23:36 | Trixar_za | :p |
22:24:18 | Araq | ugh Dave Chappelle is too hard to understand for me ;-) |
22:26:36 | filwit | lol |
22:27:52 | filwit | I've seen that DragonBall clip before, Trixar_za |
22:49:11 | dom96 | Araq: https://gist.github.com/481a029fb383ed36dd14 |
22:50:36 | Araq | looks good dom96 |
22:52:28 | dom96 | alright. |
23:43:03 | Araq | good night guys |
23:43:09 | filwit | later |
23:43:44 | filwit | someone just logged into my gmail from Tiawan |
23:43:49 | filwit | :-S |
23:51:14 | * | SchalaZeal joined #nimrod |
23:52:33 | SchalaZeal | I just noticed support for ARM and... well... thing is if ARM is going to be supported, I really recommend making a proper cross compiler if so. |