<<07-07-2012>>

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:23filwithi, Araq, I'm not sure you're around, but I was thinking about our last discussion on factory functions vs constructors
10:54:04filwitand I came to the conclusion that I like factory functions, except 'attached' to the Type itself
10:54:28filwitI'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:37filwitbut what I mean is something like this:
10:54:44filwittype Foo = object
10:54:48filwit bar : uint
10:55:27filwitproc new(f:TypeOf(Foo)) : ref Foo =
10:55:31filwit result.new()
10:55:37filwit result.bar = 2345
10:55:47filwitproc main =
10:56:01filwit var f = Foo.new()
10:56:15filwit echo f.bar # prints 2345
10:59:13filwitthis 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:22filwitany 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:49filwitSo 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:32filwitI think that having the ability to attach a Proc to a Type is a Win-Win situation, and an elegant middle ground
11:05:57filwitbut please, let me know your thoughts :-)
11:08:17filwitIf 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:53filwit....wow.... okay... probably should have tried it out a bit more before posting :)
11:11:03filwitturns out this already works if i do:
11:11:21fowluse type() instead of typeof()
11:11:22filwitproc new(f:Foo.type) : ref Foo =
11:11:42filwitfowl, ya. Just figured that out, thanks
11:11:53filwitsoo.... that's sweet
11:12:27filwitguess I'll be using that for all of my construction functions
11:17:03dom96hello everyone
11:17:13filwithi dom96
11:17:27dom96hello filwit!
11:17:49Araqfilwit: I read your suggestion
11:17:52Araqand I like it :-)
11:18:01filwitcool
11:18:03filwit:)
11:18:08AraqI will read it again this weekend though :P
11:18:20Araqthanks to NimBot these things are now logged :D
11:18:29filwithandy
11:18:31AraqI'm pretty busy with integer types btw
11:18:42AraqI've implemented my original idea
11:18:58Araqas the other solution produced bugs even in the compiler itself
11:19:08filwitwhat's happening with uint vs int?
11:19:27fowlnimrod 0.8.15 introducing int4 and int2?
11:19:48AraqI despise unsigned ints, but people moaned enough
11:19:55Araqso nimrod will get them
11:20:06Araqhowever, "uint64" is not an ordinal type
11:20:27Araqas then I'd have to use bignums in the compiler itself everywhere to model this properly
11:20:43Araqand that's too much work :P
11:20:54Araqplus I have no idea how compile times would be affected
11:21:48Araqsee http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ for why Nimrod didn't include them
11:21:50filwitwon't uint just a a 'distinct int'?
11:21:58Araqthat's possible
11:22:10Araqbut not that good for C compatibility
11:22:17filwitah, i c
11:22:53filwitstill, there shouldn't be a ton of problems since int/uint are the same size
11:23:17filwitI would think at least
11:23:26Araqthere is no problem if you don't use the full range in the first place
11:23:49Araqif you need to care about all the edge cases + overflows it's quickly an enormous effort
11:24:00Araqit's a PITA in the compiler for instance
11:24:09Araqand yet I'm pretty sure bugs remain
11:24:53Araqif you use 'int' for speed and do some graphics/game programming where the range is less than -say- 1 Million
11:25:15Araqthen you can be sloppy about these things
11:25:42filwitwell, I'm not fully aware of the challenges of super-low-level stuff like that
11:25:58filwitbut I'm sure you'll find a good solution :)
11:26:14Araqthanks
11:26:30AraqI think I found it; tests will tell today whether I was right :D
11:26:55filwitgood luck!
11:26:58Araqit's quite advanced, the compiler figures 'and 0xff' fits in a byte ...
11:28:07filwitso uint can end up being a single byte?
11:28:19Araqbasically it does interval arithmetic to be smarter
11:28:29filwitinteresting
11:28:35Araqand allows any implicit conversion that does not lose any information
11:28:56Araqand requires explicit conversions for everything it can't prove correct
11:29:37filwitbtw, 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:41filwitso you could do:
11:29:48filwitvar s = "My Name"
11:29:57filwitecho "Your name is $s"
11:30:12filwitand it would automatically format the string
11:30:24filwitanyways, just a random idea...
11:30:32Araqcheck the tests or examples for "interpolatedString"
11:30:39Araqit can be done with a macro
11:30:40filwitk
11:30:52Araq(with today's compiler)
11:30:54filwitoh, duh!
11:31:14filwitgah, Nimrod has the best macro system, I keep forgetting
11:31:17filwitone sec
11:31:25Araqwell with 0.8.14 it worked :-)
11:31:27Araqwe tested it
11:32:42filwitI'm not finding it
11:32:48filwitwhat folder is it in?
11:36:31Araqwait a sec ...
11:38:16Araqtests/run/tstringinterp.nim
11:38:25filwitkthanks
11:38:27Araqnow that was easy .... ._.
11:38:41Araqmake a proper stdlib module out of it please :-)
11:39:17Araqwith a bit better names than concatStyleInterpolation and formatStyleInterpolation ...
11:40:17filwityou want it in strutils?
11:41:01filwitI 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:16filwitbut that might be to big a change to make...
11:41:20Araqnot in strutils please ;-)
11:41:34Araqit would make strutils depend on macros.nim ...
11:41:47filwitso system.nim then?
11:41:53Araqha
11:41:59Araqthat's even worse
11:42:02filwitlol
11:42:09Araqluckily the compiler will prevent it :P
11:42:21Araqas system.nim can't import anything
11:42:22filwit(thought that already imported macro.nim ;P)
11:42:30filwitokay I see
11:42:40Araqbut you're right
11:42:40filwitso just a new lib then
11:42:48Araqpeople want it built-in
11:42:53filwitya
11:43:09Araqthe problem is that I don't as it's then useless for i18n
11:43:18filwitGoogle'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:34filwitil8n?
11:43:41Araqinternationalization
11:44:11filwitisn't the '$' common among all keyboards?
11:44:20Araqin fact, arguably it should support the 'subexes' module ...
11:44:24Araqlol
11:44:31AraqI'm talking about $ on keyboards
11:44:34Araq*not*
11:44:47AraqI'm talking about:
11:45:15Araqecho "value is $x".translateToCurrentLocale
11:45:49filwitthe formatting would happen before .translateToCurrentLocale
11:45:57filwit?
11:46:01Araqyes
11:46:09filwitthen what's the problem?
11:46:13Araqand that's wrong
11:47:04Araq"$x file[s] copied" --> becomes: $x & " file[s] copied"
11:47:17Araqideally at compile time for efficiency
11:47:34Araqbut you can't internationalize a bunch of string concatentations
11:47:50Araqyou need to keep the pattern as a single piece
11:48:02Araqonly then 'translate' can do it properly
11:48:13filwitahh... i see the problem
11:48:23filwithmm....
11:49:21filwitya that's impossible because if formating happens at compile-time and translate happens at runtime... it doesn't work
11:49:29Araqthe problem is that if we do it by a built-in it's too opinionated
11:50:02Araqsee 'subexes' for instance how IMHO *real* format strings can become
11:50:38filwitwell... if "$x file[s] copied".translate() became --> ($x & " file[s] copied").translate() wouldn't that work?
11:50:58Araqno it wouldn't
11:50:59filwitmaybe I don't see the problem...
11:51:07filwitanyways, for now I'll just make it a lib
11:51:24Araqtranslate could be a macro yes and see the &
11:52:00filwitya, true
11:52:17Araqbut that doesn't work too well
11:52:30Araqkeep in mind that "file[s]" is already hackish
11:52:50Araqand you really want to use "file" or "files" depending on the value of 'x'
11:53:31Araqsubexes include a conditional construct for this reason ...
11:54:40filwitokay, well how about "string".format() for the naming?
11:55:38AraqI dunno
11:56:37Araqmake it useful as a raw string literal identifier
11:56:38filwithmm... what about $"the string"
11:56:50filwitand put it in subex?
11:56:51Araqambiguous
11:57:00filwitsubexes**
11:57:03Araqputting it in subexes is fine
11:57:14Araqbut $"the string" doesn't work
11:57:25filwitthere's already a $string defined? what does it do?
11:57:32Araqas system.nim already has a `$`(x: string): string
11:57:38Araqit's a no-op
11:57:50filwitoh, right
11:57:58Araqin generic code you wanna say $x and get a string
11:58:10Araqno matter if it already is a string ...
11:58:22Araqit's really useful :-)
11:58:31filwitya I agree
11:58:39filwitso, what's wrong with .format?
11:58:52filwitbetter idea?
12:01:43Araqecho format"${x +y}"
12:01:51Araqhrm, not sexy enough :P
12:02:14Araqand I think $$ is already taken by marshal.nim ...
12:02:33Araqplus an operator bites with 'echo' ...
12:02:42filwitformat"..." describes what's happening though...
12:03:03Araqas 'echo $x' is parsed as '(echo) $ (x)'
12:03:39Araqformat" ..." does not 'format'
12:03:49Araqthat's what % does
12:04:09Araqformat" ... " does a compiletime string interpolation with scope capturing ...
12:04:33filwithmm.... okay
12:04:59filwitplus, if it's not an operator, people will just use "...", $x, "..."
12:05:06filwitwhen they can
12:05:21Araqwell I don't mind
12:05:22filwitor '&'
12:05:33Araqall it does is saving some characters to type
12:05:39filwitwhat about $&"..."
12:05:49Araqthat's good
12:05:55AraqI like it
12:06:08filwitkinda implies it's saving you from typing '&' all over the place
12:06:16Araq$ for "substitution" and & because it transforms into a concatenation
12:06:19filwitokay, I'll do that then
12:06:34Araqand then have $% for "formatStyleInterpolation"
12:06:46filwitokay
12:06:47Araqyummy
12:07:47filwitbut I actually need to run for a minute, I'll do this when I get back
12:14:35Araqno problem
12:28:11Araqsee you later
12:47:48dom96Well that went far: Error: unknown processor: armv6l
12:57:01filwitokay
12:57:11filwityou working on arm stuff dom96?
12:57:24dom96filwit: I got a Raspberry Pi yesterday :)
12:57:34filwitnice
12:57:34dom96So I thought: Lets test Nimrod!
12:57:40filwitgood
12:57:59dom96I think all I need to do is add that CPU to niminst's config
12:57:59filwithow's the little system, I hear they're still selling like crazy
12:58:16dom96Well it works :P
12:58:22dom96And is quite cool.
12:58:24filwit:)
12:58:31dom96Not that I have done anything interesting with it yet
12:58:40filwitwhat have you got installed on it?
12:58:48filwitArch?
12:58:51dom96yep
12:58:54filwitcool
12:59:31filwitwhat 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:09filwitbut I doubt they have Gimp and stuff right?
13:00:38dom96Take a look here: http://archlinuxarm.org/packages
13:00:54dom96So far everything that I attempted to install was there.
13:01:08dom96I haven't installed anything "graphical" yet though
13:01:11dom96just command line apps
13:01:51filwitcool, thanks for the link, I'll check it out in a sec
13:05:06filwitwow, looks like they have everything....
13:05:17filwitGimp, Inkscape, Gnome Shell
13:05:32filwitno Blender though
13:05:32dom96indeed
13:05:40dom96interesting
13:05:40filwitbut that was expected
13:07:51dom96why was it expected?
13:08:32filwitwell 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:38filwitI follow BlenderNation.org
13:09:13filwitARM graphics drivers are OpenGLES only I think, while Blender uses OpenGL
13:10:36dom96oh
13:16:40filwitbtw, dom96, it looks like your error is related to ARM6 architecture (a guess)
13:16:56dom96yes, I know what the error is
13:16:56filwitbut I thought ArchARM only ran on Arm5/Arm7
13:17:01filwitoh, okay
13:17:03dom96The csources are not generated for that architecture
13:17:15filwitah
13:17:19dom96It's an error from Nimrod :)
13:21:04dom96I would love to play around with the GPIO pins.
13:21:13dom96Looks like I'll be visiting a local electronics supplies store :P
13:21:43filwitno idea what GPIO pins are :-S
13:23:03dom96They are pins which can be used for Input or Output and can be controlled by software/
13:23:08dom96They are available on the Pi.
13:24:20filwitoh cool, so you can make an app (in Nimrod of course) to control your garage door
13:24:39dom96yep :P
13:27:36filwitdo you know if Git branches are case sensitive?
13:28:20filwitnevermind i got it
13:28:34dom96no clue
13:42:52filwitdoes Nimrod import folder names?
13:43:20filwitaka, dir: src/math/vectors.nim
13:43:34filwitdirc: src/math/matrix.nim
13:43:42dom96Yeah, I think you can do "import "src/math/matrix.nim""
13:43:44filwitimport src.math
13:43:52dom96You can't import a whole directory though
13:44:15filwitso I can't import all .nim files under a folder by just stopping at the folder?
13:44:26filwitor doing a '.*'?
13:44:32dom96You could create a file and put in it all the imports
13:44:36dom96and then just include it
13:44:46filwitokay, so it's like D then
13:45:09filwitI never did understand why you couldn't just import the whole folder like Java... but maybe there's a reason for it
13:47:21dom96Seems like it could get confusing.
13:47:28dom96If you forget what modules are in a folder.
13:47:37dom96And what the modules contain...
13:50:16filwitidk, anytime you move code around, you have to change the imports
13:50:33filwitwhich is one benefit of using namespaces like C#/C++
13:50:52filwit(though I prefer import/modules personally)
14:04:08dom96I'm sure Araq can come up with a better reason than me :P
14:04:37filwitoh I'm just complaining for complaining sake really ;-P
14:05:22dom96lol
14:05:32filwitI 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:04dom96What's the problem?
14:06:41filwitwell I'm copying the code from tests/run/tstringinterp.nim into lib/pure/subexes.nim
14:07:08filwitand renaming the functions concate/format to `$&`/`$%`
14:07:34dom96right, and?
14:07:45filwitbut while the test compiles and runs fine, my modified subexes is giving me a Internal Error: no string found
14:07:54filwiton this line:
14:08:00filwitmacro `$&` *(e: expr): expr =
14:08:08filwit var args: seq[PNimrodNode] # THIS ONE
14:08:20filwitwhoops, shit
14:08:23filwitwrong line
14:08:27filwitthis one:
14:08:42filwittemplate ProcessInterpolations(e: expr) =
14:08:43dom96Well an Internal Error means you've crashed the compiler...
14:08:49filwit var s = e[1].strVal #THIS ONE
14:09:17filwitya that's what I'm guessing, but I'm not sure why i've crashed it
14:09:22filwitI'm importing the same things
14:09:34filwitit just doesn't like the line
14:09:41filwitvar s = e[1].strVal
14:09:41dom96gist all your code please
14:09:51filwithmmm, k
14:11:04filwithttps://gist.github.com/3066595
14:11:09filwiterrors on line 339
14:13:48dom96Are you using the latest compiler?
14:14:16filwityes
14:14:22filwitjust forked and built it
14:14:26filwit0.8.15
14:15:05filwitit's odd, cause it's working with the test, but not the subexes
14:15:13filwit....but I have no idea why...
14:15:19dom96Well it compiles for me.
14:15:25filwitwhat?
14:15:29filwitwhat does?
14:15:34dom96The file
14:15:42dom96You pasted
14:15:49filwityou replaced your subexes file?
14:16:11dom96Well no. I just saved it as a different file
14:16:26filwitI made a test file, which imports subexes and uses the functions
14:16:45dom96I see.
14:16:53filwitbut I'm just copy pasting code from the tstringinterp.nim test which does compile and run
14:16:54dom96ok, gist that too then :P
14:16:58filwitk
14:18:17filwitthis doesn't work:
14:18:18filwithttps://gist.github.com/3066618
14:18:42filwitthis does work:
14:18:42filwithttps://gist.github.com/3066620
14:19:42filwitthe 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:28filwitif you notice, the functions after ### --- TEMP --- ### in the subexes file are identical to the ones int the working test source
14:20:41filwitIt's just copypasta
14:22:12dom96hrm
14:22:19filwitya...
14:23:05dom96Working on it :)
14:23:45dom96I'm pretty sure this is a bug.
14:23:59filwitThat's what I'm thinking
14:24:07filwitI guess I'll wait till Araq gets back
14:24:11dom96Some kind of difference between imported module processing and top level code processing
14:24:23dom96You can try to fix it yourself if you want
14:24:38dom96Bootstrap without -d:release and you'll get a stack trace
14:24:49filwitI'm not sure where to begin, it looks like a problem in the core expression tree structure
14:25:03filwitoh, okay
14:25:38filwitI'm actually getting a warning (as well as an error) about 'concat' being defined but never used
14:25:47filwitonly in the subexes file thought
14:25:50filwitthough**
14:25:58filwitin the working test, i don't get that warning
14:26:09dom96I doubt that has any significance
14:26:17filwitya didn't think it did
14:26:29filwitokay, i'll try bootstrapping in debug
14:27:20filwitwhat does 'koch' stand-for/mean anyways?
14:27:27filwitGerman maybe?
14:27:32dom96It means cook in German :P
14:27:44filwitah, thought it might be something like that
14:29:59filwitwhat is the order of the trace back? recent is last?
14:30:25filwitokay, never mind
14:30:30filwitjust looking at it I can tell
14:31:21filwitlooks like there's an assertion failure
14:31:22dom96yeah
14:31:36dom96The assertion is just so that it crashes and prints a stack trace
14:31:57dom96evals.nim(1110) evalMagicOrCall
14:32:04dom96That's where the error occurs
14:32:36filwityou following along with me, or something?
14:33:00dom96nah, had the stack trace in another window, thought I'd help :P
14:33:13filwitlol, well thanks for the info
14:34:05*dom96 hopes his SD card won't die from all the writes and reads
14:34:18dom96Any ideas on how many it can take?
14:34:36dom96IIRC they are quite sensitive to many writes
14:34:49filwitno idea, sorry
14:34:59filwitbuy backups :)
14:35:19dom96The SD card I got cost me almost as much as the RPI heh.
14:35:27dom96So I'm not buying any more :P
14:35:50filwitdamn, really?
14:35:54filwitI thought those where cheap
14:36:56filwitI'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:59filwitwhich is odd
14:37:36dom96yay, Nimrod is compiling.
14:37:45filwitnice
14:46:08dom96Nimrod Compiler Version 0.8.15 (2012-07-07) [Linux: armv6l]
14:46:10dom96w00t
14:47:27filwitgood work!
14:47:37dom96:)
14:47:42dom96It's quite slow.
14:48:00dom96The CPU isn't the fastest though so I'm not surprised.
14:48:04filwitI imagine it's not the fastest machine in the world
14:48:13dom96700mhz :)
14:48:37filwitplus, Nimrod takes a less direct rout to compile code than... "normal" codegens
14:49:31dom96Yeah, it goes through gcc.
14:49:31filwitI 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:37filwitI'm not sure why...
14:49:49dom96I'm sure it's not impossible./
14:50:10dom96Well, maybe there are some features that Nimrod depends on that llvm would make hard to implement
14:50:10filwitya, maybe he mis-understood what I was asking
14:50:21filwitlike what?
14:50:28dom96dunno.
14:50:37dom96I'm clueless about LLVM :P
14:51:01filwitthen how do you know LLVM would make it hard to implement :-V
14:51:41filwitanyways, I'm sure there's something
14:51:58filwitand it's not important ATM to have uber fast compilation times
14:52:46filwitit would be nice to eventually use GCC or LLVM directly, so there's no slow-downs on the parsing side
14:53:24filwitbut 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:43dom96GCC isn't that slow I don't think.
14:55:05dom96And we can use tinycc instead :)
14:56:05filwitcompared to LLVM, GCC is pretty slow
14:56:15filwitnot horrible though
14:56:23filwitand ya, there are faster ones
14:56:30filwitthough I've never used TCC
14:56:56filwitcomparing GCC compile times to C# and DMD though... it's a big difference
14:57:03filwitwhen you have a lot of code
14:57:17dom96We could also use clang.
14:58:11filwitya, and like I said, I remember someone's statics before showing that the parser wasn't the big source of slow down
14:58:20filwitit's the codegen
14:58:35filwitand C compiles much faster than C++
14:59:06filwitso parser Nimrod, then parsing C, before codegen probably isn't a big hit
14:59:13filwitcompared to the codegen itself
15:02:40dom96yeah
15:03:10filwitanyways, I'm going to head out for a bit
15:03:21dom96alright. See you later
15:03:28filwitbye
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:02Araqback
18:19:26Araqfilwit: an internal error is a bug yeah ... I'll look into it next week or so ...
18:19:44Araqvery busy with all the reported bugs and feature requests ...
18:20:10Araqand an LLVM backend is far from *impossible*
18:20:35Araqbut it adds no significant value over the current approach
18:20:54Araqand maintaining one more backend is not a small task
18:21:13Araqwe're talking about 5K lines of complex logic here
18:52:56filwithi Araq
18:53:29filwitokay, I was trying to trace the error myself, but I got a bit lost as to what could be causing it
18:53:41Araqit's the 'concat' stuff I'm pretty sure
18:53:52Araqthe warning makes the difference I think
18:54:13filwithm....
18:54:38Araqin fact ... macros still leak information
18:54:51Araqyou can't just export them and expect things to work
18:55:03filwitI can gist the stack trace, maybe if you took a look at it you could give me a hint
18:55:06Araqthe macro constructs a call to 'concat' so that needs to be exported too
18:55:22Araqalright stack trace helps
18:56:10filwitI did notice that evalAux om evals.nim only handles nkMacroStmt, and no nkMacroExpr
18:56:15filwitokay, one sec
18:56:29Araqthere is no nkMacroExpr I think
18:57:00filwithttps://gist.github.com/3066618
18:58:08Araqoh
18:58:09filwitoh, I thought there was..., I thought it might have been and bug born from your work to merge stmt and expr
18:58:35Araqlol these internal errors are no bugs
18:58:48Araqthey should simply be better error messages instead :P
18:58:57filwitI see
18:59:04Araqyou attempt to get the string value out of a node that is no string literal
19:00:03filwitit's just odd that it works in an completely isolated case, but fails when it's part of an external lib
19:00:26Araqmake it output 'renderTree(n)' in evals.nim:1110
19:00:42Araqit's not that odd
19:00:45filwitk
19:01:16Araqas I said, the macro you use builds an AST that contains access to 'concat' which isn't exported
19:01:47filwitohh... that' makes sense now
19:01:55filwitI thought that warning might be a clue
19:02:33filwitI could simply make that concat function and internal proc of both `$%` and `$&`
19:02:46Araqthe macro should bind the symbol with a built-in API I think
19:02:54Araqbut this API doesn't exist yet :-/
19:03:02Araqso yeah you have to hack around
19:03:03dom96haha, looks like i'm still a total noob at Nimrod :P
19:03:22filwityou and me both dom96
19:03:48filwit(though you know a lot more than me :-P)
19:04:01dom96Well at least you were correct to think that the warning was significant.
19:05:58filwityou're right!
19:06:02filwitit's official then
19:06:15filwitmy Nimrod skillz r the gr8test
19:06:46Araqmacros can easily be confusing ;-)
19:06:56Araqin fact, my plan is:
19:07:01filwitthat concat proc was only used by `$&`
19:07:08dom96Araq: Can I commit & push changes to get arm working?
19:07:11filwitbut it's still not working...
19:07:28Araq0.9.0 get integers and closures right
19:07:36Araq0.9.2 get templates right
19:07:43Araq0.9.4 get macros right
19:08:03Araq0.9.6 .. 1.0.0 get term rewriting macros right ;-)
19:08:41Araqdom96: no ...
19:08:47filwitnoble goals, but I hope that somewhere in there the aliasing issue between local variables and Types is addressed
19:08:58filwitthat's my single biggest annoyance at this point...
19:09:04dom96Araq: Why not?
19:09:05Araqshow the diff please dom96
19:09:15filwitsince I'm a bit OCD and hate the whole TType/PType thing....
19:09:16dom96Fine, don't trust me! :P
19:09:35dom96Araq: It's actually kind of weird. The CPU name is armv6l
19:09:39dom96Not just 'arm'
19:09:52Araqfilwit: I didn't list details like that :P
19:10:07filwitahh, cool :-)
19:10:18dom96So we will need to add it to platforms for each version I guess
19:10:30Araqand the TType PType thing is only annoying if you never used Delphi for years :P
19:10:59dom96If someone manages to obtain different machines with differing ARM CPUs.
19:11:08filwitya, never used Delphi at all...
19:11:45Araqdom96: the proper way is to adapt the build.sh script to detect any kind of ARM CPU
19:11:57Araq*not* make the compiler aware of this mess
19:12:18dom96Araq: Right, how should it be done in platform.nim?
19:12:38Araqplatform.nim already knows ARM I hope?
19:14:22dom96yeah, but the name is 'arm' will it detect 'armv6l' as 'arm'?
19:14:33dom96Well actually I know the answer to that.
19:14:37dom96Because it complained.
19:14:39dom96So it doesn't.
19:15:53Araqmake build.sh convert armv6l -> arm ?
19:16:21filwitdamn, well IDK what to do about this $%/$& thing... guess I'll just comment it out and put a #TODO on it
19:16:42filwitwhat's the preferred method to block comment? when false:
19:16:43filwit?
19:17:04dom96Araq: koch doesn't use build.sh how do you expect it to work?
19:17:07filwitor should I just remove it and do it again later since it's just copypasta to begin with
19:17:39Araqdom96: koch is built with nimrod ...
19:18:02Araqand "knows" the CPU it runs on as it's compiled into the koch executable
19:18:08Araqit all starts with build.sh ...
19:18:13dom96Araq: ok.
19:18:28Araqfilwit: whatever you feel like
19:18:33filwitk
19:18:46Araqwhat's OCD btw?
19:18:59filwitObsessive Compulsive Disorder
19:19:17Araqand why can't you do 't: TType' like me? :P
19:19:34filwitI don't actually have OCD or anything...
19:19:50filwiti don't know how you can do TType stuff
19:19:58filwitit's crazy insane man
19:20:29Araqhey it's important whether it's value or a reference semantics
19:20:57Araqoh right ... you only want reference semantics everywhere right? :P
19:21:04filwitno
19:21:14filwitbut I would like : type Foo = ref object
19:21:24filwitto _default_ to reference symantics
19:21:31filwitsemantics**
19:21:37Araqok
19:21:42Araqwell no need to argue
19:21:49Araqthe feature requests have been accepted
19:21:53filwitwasn't trying too :P
19:22:01Araqbut still I wonder:
19:22:26Araqproc copy(dest: var TMyObject, src: TMyObject) = ...
19:22:37Araqis pretty common, right?
19:22:44AraqI mean to use 'dest' and 'src'
19:22:49filwitthe 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:08filwityes, that's common
19:23:17Araqand somehow nobody writes that as:
19:23:27Araqproc copy(destMyObject: var TMyObject, srcMyObject: TMyObject) = ...
19:23:52Araqso the type is not part of the name as soon as a "better" candidate is available ...
19:24:00filwitthere's no need to stutter the type name
19:24:24Araqwhich implies you can use 1 letter parameter names for:
19:24:35Araqproc p(m: TMyObject)
19:24:42Araqand no information is lost ...
19:24:49Araqit's perfectly fine style IMHO
19:24:55Araqand once you do that
19:25:09Araqyou can easily name your types without leading T and P ...
19:25:39filwitno, not really
19:25:44filwitbut not because of parameters
19:25:53filwitbecause of local variables
19:25:57filwiti've tried
19:26:11filwitusually I'll write code like:
19:26:17filwittype Foo = object
19:26:19filwit ...
19:26:23filwitproc bar =
19:26:31filwit var foo : Foo
19:26:38filwit # whoops
19:27:09Araq var f: Foo
19:27:14filwitthe problem is that IF I want to name my types without T/P, then I'm constantly running into conflicts
19:27:47filwityes that works, and I could name it fooLocal, or fooo, or anything else
19:28:06filwitbut I don't think forcing people to avoid naming conflicts is the best solution
19:28:20filwitit would be much more elegant if this simply worked
19:28:50Araqit's 3 lines in the compiler :P
19:28:54AraqI think
19:29:06Araqit will be weird for macros
19:29:20filwit3 lines in the compiler? what is?
19:29:34filwit:-V
19:29:52Araqoh please, you simply need to make type name lookup prefer symbols of kind skType ...
19:30:11filwitI'm completely confused....
19:30:35AraqI mean: implementing the feature you desparately want
19:30:44Araqtakes like 3 lines in the compiler
19:30:59filwitoh, nice
19:31:17filwitwhy isn't it done yet then? hmmmmm?????!?!
19:31:24filwit:-P
19:31:25Araqlack of time?
19:31:52filwitwell shit, if it's that simply, point me in the right direction
19:32:04filwitwhat file is this that only needs 3 lines of modification?
19:33:22filwitI feel horribly unproductive today, with my previous attempts to modify the compiler being thorted
19:33:32Araqsemtypes.nim:187
19:33:39filwitperfect, thanks!
19:33:52Araqyou need to do a lookup that filters
19:34:37Araqoh hrm lookups.nim doesn't support that yet :P
19:34:43Araqso it's more than 3 lines
19:34:49Araqbut trivial
19:35:06filwitI'll see what I can come up with
19:35:36Araqcheckout proc SymTabGet*(tab: TSymTab, s: PIdent, filter: TSymKinds): PSym
19:35:54filwitk
19:35:59Araqlookups.nim needs a proc to access that proc
19:39:04Araqdom96: does -d:release work on ARM?
19:40:04Araqfilwit: btw zahary did some tests recently
19:40:27Araqand Visual C++ produces a much faster Nimrod compiler than GCC, LLVM and even Intel C++
19:40:46Araqit was 2.7s vs 3.2 vs 3.4 iirc
19:41:05filwithmmm.. that's odd
19:41:34Araqwhich is one reason why I want to stick with the C code gen
19:41:41filwitI would like to see actual C++ examples being faster on VC++ than G++
19:42:05filwitya, the C codegen has some nice things
19:42:38filwitand like I said, parsing is probably a negligible cost compared to codegen
19:43:02filwitso it's not a big productivity issue really
19:43:41AraqI have some problems with the "parsing" vs "codegen" distinction :P
19:44:09Araqit's really "lexing" -> "parsing" -> "semantic checking" -> "code generation"
19:44:10filwit:-)
19:44:26Araqand "semantic checking" *is* expensive
19:44:43Araqoften moreso than code gen
19:44:59filwithmmm... well good to know
19:45:10Araqbut somehow people don't even mention it :P
19:46:53Araqbtw Nimrod executes the C compiler in parallel to keep all your cores busy
19:47:21Araqbut the Nimrod compiler itself can't be parallelized easily
19:47:28filwitnice, I noticed Nimrod compiles pretty fast with the nimcache and stuff
19:47:59Araqyou should try --symbolFiles:on but it's still buggy
19:48:26filwitwell I'll avoid it for the moment then
19:48:36filwitsounds cool though
19:48:57Araqbut recompile times of 0.1s are nice :P
19:49:30filwitnice
19:49:32filwitheh, 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:48filwit(this isn't a feature suggestion, btw, just random thoughts)
19:50:18filwitso basically, what if you had "typeless" parameter that looked like weak typed programming
19:50:19filwitso:
19:50:33filwitproc foo(x, y) =
19:50:41filwit x.doSomething()
19:50:57filwit var a : int
19:51:00filwit a + y
19:51:11Araqzahary already implemented that, but I don't know the status
19:51:17filwitthen, the compiler would simply duck-type the "typeless" params are compile time
19:51:23Araqyep
19:51:25filwitreally?
19:51:28filwitthat's awesome
19:51:32Araqwe know clay ;-)
19:51:47filwitwell I don't, I came up with this independently
19:51:50filwit:)
19:52:09AraqI also want:
19:52:16filwitthat's cool though, glad to here that Nimrod will be doing something like this
19:52:30Araqproc foo(x: int; y, z; a: bool)
19:52:40Araqnote the ;
19:52:49filwitya I was just going to ask about the syntax of that issue
19:52:49Araqso that some are inferred and some are not
19:53:24filwitcool :)
19:54:28filwitthe ';' could be always used as a general 'end expr' symbol
19:54:32filwitvar a, b : int
19:54:38Araqyep, planned
19:54:39filwita = 1; b = 3
19:54:46filwitcool :)
19:54:47Araqyes yes
19:54:54Araqyour proc indentation feature is also easy to do
19:55:10Araqonly needs changes to parser.nim
19:55:22filwitwell I'm still struggling with the first problem :P
19:55:23Araqand yes it'd be nice if you could help with that
19:55:44filwityes, I would like to be able to help out with compiler stuff
19:55:52filwitit's just a bit... complex, atm
19:56:06filwitthough everything seems organized well so far
19:56:15Araqit isn't
19:56:23Araqbut still bearable
19:57:15filwitwell, once I change the symbol resolution issue, maybe refactoring some of the code is in order?
19:57:18filwit:-)
19:57:24Araqno please don't
19:57:29filwitdamnit...
19:57:56AraqI hate it when I don't know where to find my code ...
19:58:12Araqthat's far worse for my productivity
19:58:39filwitokay, I feel ya, what If I just went thought and changed a bunch of TType/PType things?
19:58:54filwit<8-D
19:59:03AraqI see
19:59:06filwitLOL
19:59:15Araqyeah I got the joke :P
20:00:46dom96Araq: 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:03filwitman I can't type today... I keep looking back and realizing I've typed things like *thought instead of *through
20:03:22Araq"It's been part of DMD2 for a while now. It allows you to do things like:
20:03:24Araqubyte lowbits(int x)
20:03:25Araq{
20:03:27Araq return x & 7;
20:03:29Araq}
20:03:30Araqwithout an explicit cast. The compiler knows that x&7 can safely fit
20:03:32Araqinside a single byte."
20:03:33Araqargh!
20:03:35AraqD already does it
20:03:36Araqdamn you, D ...
20:03:52AraqI thought Nimrod will be original with this feature ...
20:05:13filwitlol, nothing wrong with being second
20:05:20filwitthere's only so many ideas in the world
20:08:05Araqoh well
20:08:30Araqat least I am smart enough to notice that bitwise or does not adhere to simple interval arithmetic rules
20:08:37dom96pff. D. Nimrod's syntax is so much better.
20:08:49dom96D doesn't stand a chance.
20:10:14Araqand both have no chance against Rust ;-)
20:10:49filwitI didn't like Rust for some reason... I forgot why though
20:11:31filwitah, right.. pointer and namespace symbols like '->' and '::'
20:11:38dom96Araq: Have some faith.
20:11:41filwitwas one reason
20:12:03Araqfaith? against a paid team of compiler devs?
20:12:05dom96However I must admit, it does not look good.
20:12:27filwitdoes Rust even have meta programming?
20:12:31filwitwhat's that like?
20:12:32Araqwhich are not as brain dead as to leave out generics from their language?
20:12:56Araqafaik Rust's metaprogramming is not advanced yet
20:13:09filwitwhy would you want Generics when you have proper Templates?
20:13:10Araqand requires macro invokation with '#'
20:13:31filwitsomeone on the D forums figured out how you can even inherit from template functions
20:13:46filwitwhich was the only pro to Generics, If I remember correctly
20:13:55dom96Araq: I saw their roadmap just today. Maybe I shouldn't show you it, might depress you.
20:14:17Araqfilwit: I'm talking about the mystical "average programmer"
20:14:50Araqgenerics vs. templates is a lost argument for these as they don't care about the difference
20:14:55filwitah.. that fabled creator is only myth and legend ;)
20:15:17Araqdom96: show me the roadmap please
20:15:25dom96https://github.com/mozilla/rust/wiki/Note-development-roadmap
20:26:01Araqinteresting
20:26:15Araqand they don't even list the features we have planned :P
20:27:07dom96It's really unfair that they have mozilla backing them.
20:27:46dom96btw filwit any progress on that Nimrod logo mockup?
20:28:02filwithonestly, I think their syntax is a bit confusing
20:28:24filwitdom96, no, haven't worked on anything Nimrod related in awhile
20:28:29filwitbut I'll complete it
20:28:35dom96Great :D
20:28:45dom96I haven't actually used Rust, D, or Go.
20:29:09dom96Ever since I found Nimrod I've been using it, heh.
20:29:46filwitI've used D and played with Go a few times
20:29:56filwitnot a fan of Go, but D has some great things
20:30:02filwitmost of which Nimrod has
20:30:09filwitand does better, IMO
20:30:20dom96The C-like syntax really pushes me away from those languages.
20:30:20Araqha thanks
20:30:47filwitthe fact that there's no distinctions between Macro/Template/Proc use is something I think is really great about Nim
20:31:10filwitcause reading through code, all you're doing is tracing "function" calls, like in C
20:31:18filwitit's just easy to read and understand
20:32:04filwit(which is why I'm so against TType/PType stuff, not to bring that up again)
20:32:21filwitlooking through Rust, it looks like it's got a lot of power
20:32:33filwitbut I'd rather use D (between the two)
20:32:43filwitbecause D is easier on the eyes
20:32:58filwitthough Rust's pattern matching is interesting
20:33:45filwitdom96: I'm fine with the C like {} syntax
20:34:02filwitbut one thing I really like about Nimrod is it's case-insensitivity
20:34:18dom96The reason Nimrod caught my eye in the first place is its python-like syntax.
20:34:40dom96Back then I was really into and I just wanted a python which compiled to C.
20:34:45filwitnotice on the roadmap their talking about universalizing the capitalization between old and new libs
20:34:46dom96*into python
20:35:09filwitsee, the Python syntax had the opposite effect on me
20:35:22filwitI almost passed Nimrod up completely after seeing a code example
20:35:34filwitbut the feature list on the home page kept me reading
20:35:34Araqwhat?
20:35:55Araqyou actually like nimrod's case insensitivity?
20:36:01Araqinteresting :-)
20:36:18filwitya, and the fact that '_' is just their for fluff
20:36:30filwitit means I can use other's libs in the style I want
20:36:33filwitwhich I like
20:36:43Araqwell that was the point :-)
20:37:08Araqbut would I do it again?
20:37:14Araqunlikely ;-)
20:37:20filwitlot of problems?
20:37:27AraqI would make the compiler enforce the naming convention instead
20:37:33filwitit obviously wont work with linking to C and such
20:37:42dom96haha.
20:37:44filwitlol
20:37:48dom96That would certainly make people angry.
20:37:51filwitall or nothing eh
20:37:56Araqin fact there are suprisingly little problems with C libs
20:38:06Araqand Nimrod's case insensitivity
20:38:19AraqI was suprised how few clashes it produces :D
20:38:34Araqno, I still like the insensitivity way
20:38:48Araqthe reason why I would do it differently has to do with *people* :P
20:38:48filwityes, I'm glad you didn't enforce a standard
20:39:12Araqbecause many people really dislike it
20:39:15filwitcause if it was foo_bar() I probably wouldn't have read any further :P
20:39:39filwitreally? others don't like the case insensitivity?
20:39:52Araqyeah
20:39:55Araqmany dislike it
20:39:55filwitI told my brother about it, and he was against the idea... but he usually is
20:40:02dom96It's always the first thing they complain about
20:40:03filwitmostly because he does this:
20:40:08filwitclass Foo {
20:40:22filwit private in bar;
20:40:31filwit public int bar() {...}
20:40:32filwit}
20:40:38filwitshit
20:40:41filwitshould be:
20:40:48filwit public int Bar() { ...}
20:41:12filwitbasically all public members are capitalized (C#), and privates are lower camelCase
20:41:33Araqprivates are _thisWay in C# :P
20:41:41filwitusually, I know
20:41:57filwitbut we don't do that in our SDK
20:41:57Araqpublic Foo Foo { get; set; }
20:42:19AraqC#'s style guidelines don't make any sense anyway
20:42:36filwitmeh, I like them well enough
20:42:38Araqpublic Foo Foo { get; set; } // doesn't compile
20:43:26filwitya, I was always torn between PascalCase and camelCase
20:43:56filwitin one way, PascalCase is more consistent, but in other camelCase has nice distinction between types/locals
20:43:59dom96TIL that's called PascalCase
20:44:29filwitI usually use camelCase, but Reign SDK is PascalCase, so I'm use to both
20:45:05filwitI usually just use whatever the language recommends
20:45:12Araqat work I "program" quite some SQL :-)
20:45:31Araqit's soooo convenient to not have to care about this crap in a REPL
20:45:46filwitexcept 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:59filwit;D
20:46:44AraqI don't mind :P
20:47:46Araqas I know time also deals with these things; nobody moans about time_t in C :P
20:48:12Araqtime_t is from the gods and if you don't like it it's *your* problem
20:48:23Araqin fact
20:48:41Araqeverything in C is the *programmer's* fault XD
20:48:48filwitlol
20:49:15filwitpeople don't complain about C, because to start down that path is to enter insanity
20:49:38Araqpeople worship C and UNIX
20:49:46filwitI know
20:50:13dom96and vim
20:50:24dom96Don't forget about vim :P
20:50:41Araqno! emacs!
20:50:49filwitokay, I understand how C is popular, but I never understood Vim's keyboard shortcuts
20:50:59filwit'h' as up?
20:51:06dom96What you mean that OS?
20:51:06filwitand 'l' and down?
20:51:26dom96I can run quake in my emacs, it's obviously far better than vim!
20:51:27filwitbut granted, I haven't given Vim much time of day
20:52:11Araqwell every other widget in the OS uses the common cursor keys
20:52:12dom96yes, why make arrow keys work when you can use letters to move the cursor!
20:52:27Araqso it's unproductive to learn Vim
20:52:39dom96They could have at least used something like WASD
20:52:55Araqdom96: 'W' didn't exist back then
20:53:05Araqthe letter 'W' was invented much later ...
20:53:25dom96oh, did the ancient Mayans invent vim?
20:53:38Araqyep :P
20:53:49filwitthat explains it
20:54:44dom96Some poor calendar maker must have forgotten how to move the cursor and just gave up on finishing the calendar.
20:55:11filwitthe mystery is solved
20:55:46filwitmaybe at the end of the year, all Vim software will spontaneously erase itself
20:56:00dom96That would be great. lol.
20:56:12filwitand all the Vim folks will end their lives thinking it's the end of the world
20:58:29filwitlooks like they found the Higgs boson
20:58:38Araqyeah
20:58:47Araqunfortunately
20:58:57filwityou had a better theory?
20:58:57AraqI'd have preferred if they hadn't found it
20:59:00dom96Not sure what benefit that really brings.
20:59:02filwitlol
20:59:03Araqlol no
20:59:19dom96He wanted to find it himself.
20:59:21Araqbut the standard theory is so ugly
20:59:39dom96Using the Nimrod hadron collider simulator.
20:59:42Araqit'd be nicer if something would prove it wrong
21:00:05Araqhttp://www.osnews.com/story/25556 btw still my favourite
21:00:14filwitdom96: 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:47filwitAraq: I don't really know all that math jumbo...
21:01:18filwitnew standard theory:
21:01:35filwitproc main : {.magic.}
21:02:02Araq"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:11dom96Araq: Do you know much about the longevity of SD cards?
21:22:27AraqSSD?
21:23:36dom96No. Secure Digital: http://en.wikipedia.org/wiki/Secure_Digital
21:26:41AraqI dunno
21:26:49AraqI would be careful with it ;-)
21:27:22Araqas I've seen quite some SSD break when you're doing many writes
21:27:53AraqSSD sounds similar to SD so it should be similar for these :-)
21:28:15Araqthat doesn't really make much sense
21:28:32Araqbut it's interesting to notice how one's own brain "works"
21:29:20dom96hrm? What doesn't make sense?
21:30:35Araqread it again
21:36:33dom96i see. Well they are quite similar.
21:36:38dom96Both use flash storage.
21:36:52Araqyeah I noticed that later too
21:36:55*Trix[a]r_za is now known as Trixar_za
21:45:15Trixar_zafilwit really does have a one track mind, hey?
21:46:11filwiteh?
21:46:27Trixar_zaThe last 3 times I've seen you talk, it's been about factories
21:46:28Trixar_za:P
21:46:41Trixar_zaAnd how they're superior
21:46:53filwitoh, lol
21:47:03filwitI was actually arguing in favor of Constructors before
21:47:17filwitbut yes, it's been an on-going discussion
21:47:25Trixar_zalol, shows you how I have half-read stuff :P
21:47:28AraqI was arguing in favor of factories
21:47:43Araqthough I don't really like them XD
21:47:52filwitnow I'm in favor of Factories (applied to Types)
21:47:59Trixar_zaClearly I side with Araq - mostly because he has the cookies
21:48:04filwitso, var foo = Foo.new(...)
21:48:21dom96Araq has cookies?
21:48:27filwitoh, well that's understandable... because of the cookies
21:48:31Araqif you need a factory, you want to abstract a type hierachy away
21:48:35dom96How do I not know of this!?
21:48:46Araqwhich leads to the question:
21:48:57Araqwhy have the type hierachy at all in the first place?
21:49:07Araquse a sum type instead
21:49:20Araqhowever, unfortunately; it can't always be avoided
21:49:42filwitI think type hierarchy is logical
21:49:50filwitwe sort of classify things that way naturally
21:50:00filwitbut idk, whatever works best
21:50:17Araqhierarchies suck IMO ;-)
21:50:31AraqSystem.IO.Text.FileReader
21:50:44Trixar_zaAh, I was just about to ask if it has to do with that
21:50:47Trixar_za:P
21:50:54filwitwhat's wrong with that?
21:51:00AraqSystem.Properties.Settings.Argh
21:51:10Araqit's arbitrary
21:51:13filwitat least you know where things are coming from
21:51:16Araqthat's wrong with it
21:51:27Araqit's bureaucratic too
21:51:38Trixar_zaLike with python: self.wrap(string.str()).split()
21:51:41Araqwhy not Universe.System.IO?
21:51:48Araqwhy not Multiverse.Universe.System.IO?
21:51:53filwitbecause we program on computers?
21:51:58filwitand not universes
21:52:04Araqwhy not Settings.Properties?
21:52:13Araqwhat's the difference between them anyway?
21:52:19filwitthat's acceptable
21:52:32Trixar_zaoh right and don't forget self.wrap(string.str()).time.sleep(10)
21:52:48filwitI'm just in favor of understanding over abbreviation
21:53:09Trixar_zaActually that's all bad examples from me ;P
21:53:13filwitif 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:31Araqit's all coming from .NET :P
21:53:32filwitthat's why hierarchy classification is, IMO, good
21:54:36Trixar_zamd5sum = hashlib.md5(title+desc).hexdigest()
21:54:42Trixar_za^--- real life example
21:56:10Trixar_zaWell, made a little pretty of course
21:56:17Trixar_zaOtherwise it will be one hell of a long line
21:57:01dom96You can import things from directories in Nimrod can't you? i.e. import "Package/module"
21:57:07dom96As long as that is possible I am happy.
21:57:55dom96Because if you have large libraries you want to have modules with name like 'types.nim'
21:58:12dom96and if you want to use multiple libraries these would clash without putting them into their own dirs.
21:58:36dom96Well I guess you could always just name them: LibraryTypes.nim
21:59:07Trixar_zamd5sum = hashlib.md5(((item.title+item.description).strip("Live Scores: ").replace("#", "")).encode("utf-8")).hexdigest()
21:59:10Trixar_zaI was bored
21:59:22Trixar_zaThis is why you shouldn't write one liners in Python
21:59:22Trixar_za:P
22:00:03dom96Trixar_za: Were you trying to obfuscate your code at the same time as writing it?
22:00:47Trixar_zaActually I'm using the md5sum to keep track of the rss feeds the bot has shown
22:00:51Trixar_zaDoesn't always work
22:01:03Trixar_zaMostly because python's hashlib sucks by design
22:01:42Trixar_zafeedparser rocks though
22:04:21Trixar_zaWhich reminds me, how does error handling work in Nimrod?
22:05:02Araqexceptions or return values
22:05:15Araqmostly exceptions
22:05:34Araqbut thanks to 'discard' return values are possible too
22:10:19Trixar_zaOh yeah, discard :P
22:11:01filwitis there a reason you set things to nil in Nimrod on initialization?
22:11:07filwitvar ident: PIdent = nil
22:11:19filwitisn't it defaultly nil?
22:12:27Araqyeah I'm just more explicit sometimes
22:12:35filwitokay, just woundering
22:12:38filwitwondering**
22:12:44Araqplus most of the code has been translated from Delphi :P
22:12:57Araqand Delphi has no implicit initialization
22:12:58filwitit was originally written in Delphi?
22:13:04Araqyeah
22:13:13filwitinteresting
22:13:24Araqwell ... the common subset of Delphi and Nimrod, in fact
22:13:36dom96I thought it was pascal?
22:13:46dom96Is there a big difference between the two?
22:13:47Araqthere is no meaningful difference, dom96
22:13:51dom96i see
22:16:40AraqTrixar_za: http://www.youtube.com/watch?v=feAlOzra7LQ&feature=related
22:18:41Trixar_zaOne Nipple "AhAhAh"
22:20:52filwitreminds me of Dave Chappelle, lol
22:20:57filwithttp://www.youtube.com/watch?v=xCbU_11hx8Y
22:23:03Trixar_zaMind you, I forgot about the Japanese version of Dragonball featuring Goku finding out the Bulma lacks a penis and balls
22:23:35Trixar_zaClearly the Americans can't deal with jokes like that
22:23:36Trixar_za:p
22:24:18Araqugh Dave Chappelle is too hard to understand for me ;-)
22:26:36filwitlol
22:27:52filwitI've seen that DragonBall clip before, Trixar_za
22:49:11dom96Araq: https://gist.github.com/481a029fb383ed36dd14
22:50:36Araqlooks good dom96
22:52:28dom96alright.
23:43:03Araqgood night guys
23:43:09filwitlater
23:43:44filwitsomeone just logged into my gmail from Tiawan
23:43:49filwit:-S
23:51:14*SchalaZeal joined #nimrod
23:52:33SchalaZealI 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.