| 00:02:41 | * | darithorn joined #nimrod |
| 00:21:21 | * | Sphax quit (Quit: Quitte) |
| 00:29:44 | * | q66 quit (Quit: Leaving) |
| 00:40:57 | * | EfTwelve joined #nimrod |
| 00:48:41 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 00:53:51 | * | darithorn quit () |
| 00:54:04 | * | uuu joined #nimrod |
| 00:54:49 | dom96 | hi uuu |
| 00:55:16 | uuu | Hi dom96 |
| 01:53:56 | * | brson quit (Ping timeout: 268 seconds) |
| 02:02:12 | * | sinistersnare joined #nimrod |
| 02:04:16 | sinistersnare | can someone please console me on this? https://gist.github.com/Gibstick/6342308 |
| 02:04:46 | sinistersnare | im trying to get nimrod working (and of course im getting 100kb/sec while downloading this) and found that... |
| 02:07:09 | reactormonk_ | sinistersnare, don't overkill it |
| 02:08:09 | sinistersnare | i tried downloading the source build from /download.html but it gave me some 'returned ld 1' error |
| 02:08:13 | sinistersnare | so im trying from github |
| 02:09:09 | reactormonk_ | try -depth 1 next time |
| 02:09:19 | reactormonk_ | --depth 1 |
| 02:09:23 | reactormonk_ | ... when cloning. |
| 02:09:32 | sinistersnare | why? |
| 02:10:29 | reactormonk_ | creates a shallow clone |
| 02:10:59 | sinistersnare | oh |
| 02:12:11 | sinistersnare | just wondering: is there any chance of building packages for linux distros? |
| 02:13:01 | reactormonk_ | a nimrod package or building packages of nimrod software? |
| 02:13:21 | * | reactormonk_ is now known as reactormonk |
| 02:13:26 | sinistersnare | a nimrod package for debian, prebuilt and the like |
| 02:13:34 | sinistersnare | im a linux newbie, but i love the idea of packages |
| 02:13:41 | sinistersnare | and i saw windows has an installe r:p |
| 02:26:48 | * | EfTwelve_ joined #nimrod |
| 02:30:28 | * | EfTwelve quit (Ping timeout: 264 seconds) |
| 02:30:43 | * | EfTwelve_ is now known as EfTwelve |
| 02:39:39 | * | ltbarcly joined #nimrod |
| 02:44:10 | * | ltbarcly quit (Ping timeout: 256 seconds) |
| 02:49:59 | * | ltbarcly_ joined #nimrod |
| 02:54:29 | * | ltbarcly_ quit (Ping timeout: 248 seconds) |
| 03:04:30 | * | XAMPP-8 joined #nimrod |
| 03:05:10 | * | ltbarcly_ joined #nimrod |
| 03:09:50 | * | XAMPP-8 quit (Ping timeout: 240 seconds) |
| 03:11:21 | sinistersnare | yay i got it working :D |
| 03:11:31 | * | brson joined #nimrod |
| 03:11:38 | * | noam__ quit (Ping timeout: 264 seconds) |
| 03:12:50 | * | ltbarcly_ quit (Quit: Computer has gone to sleep.) |
| 03:17:01 | * | Endeg quit (Read error: Connection reset by peer) |
| 03:32:02 | * | brson quit (Quit: leaving) |
| 03:32:04 | * | jdpo joined #nimrod |
| 04:01:38 | * | jdpo is now known as jdpo|away |
| 04:06:33 | * | ehaliewicz joined #nimrod |
| 04:11:09 | ehaliewicz | does nimrod have a goto statement? |
| 04:12:30 | * | Associat0r quit (Quit: Associat0r) |
| 04:13:09 | sinistersnare | ehaliewicz: from what ive read, you can label blocks then break to them |
| 04:13:24 | sinistersnare | http://nimrod-code.org/tut1.html#break-statement |
| 04:13:59 | ehaliewicz | looks like that will jump out of a block |
| 04:14:05 | ehaliewicz | i guess that could achieve some of the same effect |
| 04:14:11 | ehaliewicz | but it's not exactly what i'm looking for |
| 04:14:48 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:15:17 | Trixar_za | http://xkcd.com/292/ |
| 04:15:44 | ehaliewicz | well, either goto or proper tail calls |
| 04:15:50 | ehaliewicz | but you can't guarantee tail calls with C |
| 04:16:04 | ehaliewicz | it's helpful when you write generated code, or something like an emulator |
| 04:22:17 | * | noam joined #nimrod |
| 04:29:54 | * | ltbarcly_ joined #nimrod |
| 04:36:38 | * | jdpo|away quit (Quit: Bye!) |
| 04:37:18 | * | j03 joined #nimrod |
| 04:38:46 | * | j03 quit (Client Quit) |
| 04:41:24 | * | jD joined #nimrod |
| 04:41:37 | * | jD is now known as Guest96810 |
| 04:43:38 | * | Guest96810 quit (Client Quit) |
| 04:44:05 | * | jd^ joined #nimrod |
| 04:45:50 | * | jdp quit (Quit: IRCRelay - http://ircrelay.com) |
| 04:50:59 | * | jd^ quit (Quit: Bye!) |
| 04:51:26 | * | jd^ joined #nimrod |
| 04:59:58 | * | jd^ quit (Quit: Bye!) |
| 05:00:30 | * | jd^ joined #nimrod |
| 06:29:47 | * | uuu quit (Read error: Connection reset by peer) |
| 06:34:34 | * | jd^ is now known as jd^|away |
| 07:16:05 | * | Araq_ joined #nimrod |
| 07:17:49 | oal | From reddit: https://gist.github.com/Gibstick/6342308 |
| 07:18:42 | oal | Why isn't the nimrod compiler more strict than that? |
| 07:18:46 | Araq_ | sinistersnare: niminst supports building debian packages, other package managers can be added |
| 07:19:45 | Araq_ | oal: oh that gist. Is quite funny. I can easily come up with something very similar for -say- Java. |
| 07:20:35 | oal | Makes me think of PHP and its case insensitivity :( |
| 07:22:17 | vegai | oal: yea, that seems a bit unfortunate |
| 07:22:32 | vegai | although the actual harm in real code probably isn't that bad |
| 07:22:44 | vegai | any sane codebase is checked in via code reviews anyway |
| 07:23:04 | vegai | but somehow I still feel that's a bit apologist |
| 07:23:17 | oal | yeah, programmers do the weirdest things |
| 07:25:00 | * | Boscop joined #nimrod |
| 07:25:22 | Araq_ | PHP is only case insensitive for function names iirc |
| 07:26:27 | oal | mhm, long time since I touched PHP. |
| 07:27:01 | vegai | I have used a language that has even more horrible convention |
| 07:27:03 | oal | Is there a good reason why Nimrod allows that gist to pass? |
| 07:27:16 | Araq_ | yes |
| 07:27:18 | vegai | openedge 4gl: it allows not only case insensitity but actual abbrevations of almost everything |
| 07:27:27 | vegai | including things like keywords and table names |
| 07:27:31 | * | Boscop left #nimrod (#nimrod) |
| 07:28:33 | Araq_ | http://forum.nimrod-code.org/t/191 might happen when you nag me enough about it |
| 07:29:06 | Araq_ | http://forum.nimrod-code.org/t/182 |
| 07:29:57 | Araq_ | https://github.com/Araq/Nimrod/issues/521 |
| 07:30:14 | Araq_ | so read it and feel free to disagree |
| 07:30:43 | Araq_ | but "omg it's like Visual Basic" is not an argument |
| 07:31:42 | ponce | no one ever programmed in Pascal ? case insensivity is not big deal |
| 07:32:02 | vegai | yeah, it probably is a silly detail |
| 07:32:08 | EfTwelve | i like the case insensitivity myself |
| 07:32:16 | oal | Araq_, thanks |
| 07:43:20 | Araq_ | ehaliewicz: no goto and tail calls only in so far the C backend supports it (all major C compilers have this optimization though) |
| 07:44:35 | oal | +1 to the case sensitivity from me |
| 07:44:56 | oal | Looks like a good plan |
| 07:45:01 | Araq_ | you know *why* the +1 would be helpful |
| 07:45:19 | nihathrael | I agree, I'd prefere case sensitivity |
| 07:54:04 | * | ltbarcly_ quit (Quit: Computer has gone to sleep.) |
| 07:54:52 | nihathrael | it is especially easier for newer programmers I think, I remember constantly being unsure of what a certain identifier in the code meant because I could not figure out if it was a class/type/method ad the point I was currently reading it |
| 07:55:23 | * | jd^|away quit (Quit: Bye!) |
| 07:55:44 | nihathrael | also about project specific styles, I don't think there is any benefit for project specific styles except for people feeling in control and having "their" way. It really only introduces friction when new people want to join, because they have to learn the project style |
| 07:56:33 | nihathrael | patches have to fixed |
| 07:57:05 | nihathrael | just because "the new guy" missed part x.y.z of the project's coding style |
| 07:57:31 | nihathrael | + every time someone new joins the project you will have discussions about the style again |
| 07:57:47 | oal | I posted my opinion to the thread: http://forum.nimrod-code.org/t/191/3#1020 |
| 08:00:11 | ponce | I'd like to see actual studies about the impact of case sensivity, since I can't remember a bug with case insensivity, only grepping sessions, while I can remember bugs with one letter variable i and I |
| 08:01:04 | Araq_ | oal: thanks |
| 08:04:57 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 08:09:35 | * | ehaliewicz quit (Ping timeout: 245 seconds) |
| 08:20:38 | * | zahary_ joined #nimrod |
| 08:27:15 | * | ehaliewicz joined #nimrod |
| 08:33:31 | * | Araq_ joined #nimrod |
| 08:33:42 | * | ehaliewicz quit (Ping timeout: 264 seconds) |
| 09:19:48 | * | q66 joined #nimrod |
| 09:24:11 | Araq_ | ponce: Guido did some usablity tests and wanted to change Python to be case insensitive iirc |
| 09:24:28 | Araq_ | also most people remember the sound of a word and not its spelling ... |
| 09:25:15 | Araq_ | that's why everybody can speak and many many people can't write ... |
| 09:30:58 | ponce | interesting results |
| 09:32:45 | ponce | it feels wrong to be able to use x for one purpose and X for another( like it happen in code I write) |
| 09:32:50 | * | EXetoC joined #nimrod |
| 09:38:56 | Araq_ | ponce: interesting. It's the one thing I like about case sensitivity. X vs x is useful in math heavy code ... |
| 10:09:42 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 10:41:46 | * | Araq_ joined #nimrod |
| 10:42:06 | * | Araq_ quit (Client Quit) |
| 11:23:22 | EXetoC | getting the order right on these big compiler arrays can be tricky, but hopefully there aren't too many of them |
| 11:24:10 | EXetoC | I'm about halfway through now, and I just get "FAILURE" when compiling. I'll see what happens when the rest of the stuff has been fixed |
| 11:54:31 | * | BitPuffin joined #nimrod |
| 12:08:16 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 12:11:42 | * | Associat0r joined #nimrod |
| 12:11:42 | * | Associat0r quit (Changing host) |
| 12:11:42 | * | Associat0r joined #nimrod |
| 12:28:26 | * | Araq_ joined #nimrod |
| 12:30:17 | EXetoC | Entering VM territory now |
| 12:30:20 | * | Araq_ quit (Client Quit) |
| 12:33:26 | dom96 | hello |
| 12:33:36 | dom96 | EXetoC: what are you up to? |
| 12:35:49 | EXetoC | dom96: Adding code paths for float32 |
| 12:39:30 | EXetoC | and I might be able to watch the tests blow up once I manage to resolve this "FAILURE" error |
| 12:40:32 | EXetoC | I just ignored it and carried on, so we'll see what happens :> |
| 12:50:35 | EXetoC | dom96: floating-point operations often yield results of type 'float' no matter what type the parameters have. I think that's what he was getting at |
| 12:56:39 | dom96 | are you editing the compiler for that? |
| 13:00:02 | EXetoC | ok omitting -d:release this time gives me a better error message in addition to just "FAILURE". I though I tried this before |
| 13:00:04 | EXetoC | dom96: yeah |
| 13:00:57 | EXetoC | many operations ending with F64 for example, don't have corresponding ones ending with F32 |
| 13:34:55 | oal | Araq, "everybody can speak and many people can't write". At the same time one can say that it's important that things are spelled correctly. "c u l8r" is understandable, but looks terrible. |
| 13:35:59 | oal | Therefore I prefer a consistent grammar and way of spelling, be it in a programming language or any other kind of language |
| 13:38:35 | * | faassen joined #nimrod |
| 13:54:33 | EXetoC | Araq: so TNode uses intVal for all integer types, but do I need a separate member for 32-bit floats? |
| 14:00:09 | EXetoC | and what about newFloatNodeT and getFloat? Do I need new variations of those or do I just need to add branches to the case statements? |
| 14:45:23 | zahary_ | I'm not looking at the code right now, but intVal is defined as BiggestInt and it hold the int value for all int types |
| 14:45:36 | zahary_ | I would guess that the same goes for floatVal (it's double internally) |
| 14:46:03 | zahary_ | you probably don't need to change this particular aspect |
| 14:47:31 | EXetoC | right |
| 14:51:57 | * | uuu joined #nimrod |
| 14:55:07 | * | Araq0 joined #nimrod |
| 14:56:00 | Araq0 | Exetoc youre doing this too complicated |
| 14:56:59 | Araq0 | You should use the same magics and distinguish only in the c backend |
| 14:57:43 | Araq0 | Constant folding should still work in 64 bits |
| 14:58:02 | Araq0 | Thats what c does too btw |
| 14:59:13 | Araq0 | You only need to edit some format strings in the compiler |
| 15:05:21 | * | Araq0 quit (Quit: Bye) |
| 15:08:39 | EXetoC | so that's a total of about 3 locations that need to be edited, right? 4 counting with the VM, which I can deal with in some commit |
| 15:11:47 | EXetoC | modules I mean |
| 15:16:48 | EXetoC | should be done soon then |
| 15:25:12 | * | d34th quit (Ping timeout: 260 seconds) |
| 15:26:33 | * | d34th joined #nimrod |
| 15:48:40 | * | circ-user-6tksC joined #nimrod |
| 15:49:51 | * | Mat2 joined #nimrod |
| 15:49:53 | Mat2 | hello |
| 15:54:15 | nebiros | Mat2: hey! |
| 15:54:43 | * | ltbarcly_ joined #nimrod |
| 15:56:23 | circ-user-6tksC | hi, i am trying to figure out what "mixin" in nimrod could do. i saw the example in manual and it seems to be just like the "extern" in C to declare an open symbol? is it more powerful than this? |
| 15:56:50 | Mat2 | hi nebiros |
| 15:59:27 | * | brson joined #nimrod |
| 16:01:31 | Mat2 | circ-user-6tksC: sorry, I have no experience with this |
| 16:01:47 | Mat2 | hi brson |
| 16:02:53 | circ-user-6tksC | thanks Mat2. i guess Araq is not here? he should be the one know this the best:) |
| 16:03:00 | EXetoC | extern? I don't know about that |
| 16:03:07 | EXetoC | see tests/run/mixin.nim |
| 16:03:23 | Mat2 | hi EXetoC |
| 16:04:25 | circ-user-6tksC | thanks EXetoC. Will take a look |
| 16:04:50 | Mat2 | circ-user-6tksC: not currently as I see |
| 16:05:18 | EXetoC | hi |
| 16:06:03 | EXetoC | also: https://github.com/Araq/Nimrod/blob/master/todo.txt#L11 |
| 16:13:25 | circ-user-6tksC | ye, saw this for version 0.9.4: introduce 'mixin'. seems nothing about what the 'mixin' will do. it seems Araq quite against polymorphism with interface, abstract type etc. I am trying to figure out if anything similar is provided and will be providded |
| 16:16:12 | circ-user-6tksC | I saw Araq mention "The feature you want here are more expressive type constraints; and indeed that's a planned feature." at this thread: http://forum.nimrod-code.org/t/145. anyone know his plan on this? |
| 16:16:59 | Mat2 | you should wait until he's active and ask him |
| 16:17:15 | circ-user-6tksC | ok, thanks Mat2 |
| 16:21:06 | * | Mat2 what make me always wonder is the the saged demandment for polymorphism *and* efficient, static compilation |
| 16:25:12 | EXetoC | nothing wrong with that |
| 16:26:21 | Mat2 | I mean the complexity for compilation, not its result |
| 16:28:04 | * | EfTwelve quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 16:28:37 | * | faassen left #nimrod (#nimrod) |
| 16:52:57 | * | DAddYE joined #nimrod |
| 16:54:00 | Mat2 | hi DAddYE |
| 16:54:29 | DAddYE | hi Mat2 |
| 16:59:19 | EXetoC | Can the tests be executed in parallel? |
| 17:01:11 | dom96 | no |
| 17:01:41 | Mat2 | EXetoC: Can you take a look at the swedish translation of my compiler documentation after finishing ? That would be nice |
| 17:09:48 | EXetoC | Mat2: yeah |
| 17:09:53 | Mat2 | thanks |
| 17:10:08 | * | brson quit (Ping timeout: 245 seconds) |
| 17:10:11 | dom96 | Getting the tester to split up the running of tests into however many cores are available might actually be a good idea. |
| 17:10:35 | dom96 | Mat2: Do you have any English documentation? I would like to read it out of curiosity. |
| 17:11:22 | Mat2 | not currently but end of next week |
| 17:11:34 | EXetoC | yeah. I might give it a go if no one else wants to |
| 17:11:36 | Mat2 | only german at moment |
| 17:11:37 | dom96 | alright |
| 17:14:15 | * | brson joined #nimrod |
| 17:17:40 | * | io2 joined #nimrod |
| 17:19:53 | Mat2 | coes someone know how I pass a const as procedure parameter ? |
| 17:19:57 | Mat2 | ^does |
| 17:20:30 | dom96 | Just pass it as your normally would? |
| 17:20:37 | dom96 | *you |
| 17:21:08 | Mat2 | ok, and what type has these constant defination then ? |
| 17:21:37 | dom96 | whatever type the const value has: |
| 17:21:39 | dom96 | const x = 5 |
| 17:21:55 | dom96 | proc foo(y: int) = ...; foo(x) |
| 17:22:28 | Mat2 | this means implicit type conversion I think |
| 17:22:54 | EXetoC | why? |
| 17:23:15 | dom96 | All proc params are const by default I think. |
| 17:23:20 | dom96 | Since you can't modify them. |
| 17:23:30 | dom96 | Unless you prefix them with 'var' |
| 17:23:55 | dom96 | proc foo(y: var int) = ...; foo(x) # will fail |
| 17:24:06 | * | brson quit (Ping timeout: 264 seconds) |
| 17:24:13 | Mat2 | well const test = 0xFFFFFFFFFFFFFFFF |
| 17:24:34 | Mat2 | for example and foo (y: int) |
| 17:24:49 | * | brson joined #nimrod |
| 17:25:53 | Mat2 | or const test = 0xFFFFFFFFFFFFFFFF'u64 |
| 17:32:28 | * | DAddYE_ joined #nimrod |
| 17:33:02 | Mat2 | ok, I can use the largest type possible of course |
| 17:35:49 | * | Widdershin quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:36:02 | * | Widdershin joined #nimrod |
| 17:36:15 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 17:37:10 | Mat2 | but that's not an elegant solution |
| 17:37:51 | EXetoC | I don't know what you're trying to do. do you want the type to be generic? |
| 17:38:37 | Mat2 | I want the proc to be generic, dependent of the constant type |
| 17:38:54 | * | Widdershin quit (Client Quit) |
| 17:40:17 | EXetoC | I don't know why you want it to be tied to the type of the constant |
| 17:41:53 | EXetoC | proc f(x: TInteger)? |
| 17:42:08 | * | Widdershin joined #nimrod |
| 17:43:56 | * | Widdershin quit (Client Quit) |
| 17:44:02 | EXetoC | where TInteger is a type class (see system.nim). you can also create your own type classes if you want |
| 17:44:05 | Mat2 | that's a bit tricky: I have defined constants for the max. lenght of immediate parameters of the used opcodes (that's the code-generation part). This way I can check up range errors at compile time |
| 17:44:12 | EXetoC | "proc f(x: int32|int64)" |
| 17:44:54 | Mat2 | the ranges hereby can vary from 8 bit immediate values to 32 bit ones |
| 17:45:37 | * | ehaliewicz joined #nimrod |
| 17:45:40 | Mat2 | if I pass these constants with the greatest type, I must check them manually |
| 17:46:03 | dom96 | hello ehaliewicz |
| 17:47:04 | Mat2 | which means dynamic at runtime |
| 17:47:11 | zahary | Mat2: what you need is |
| 17:47:11 | zahary | proc foo(x: expr[string]) |
| 17:47:36 | zahary | expr[string] means compile-time, static value of type string |
| 17:47:55 | Mat2 | thanks zahary |
| 17:47:55 | zahary | be warned that it's not documented yet and it will be renamed to static[string] in the future |
| 17:48:04 | Mat2 | good to know |
| 17:48:08 | zahary | makes the proc generic just like you asked |
| 17:48:18 | EXetoC | ok that's entirely different |
| 17:48:30 | * | DAddYE_ quit (Remote host closed the connection) |
| 17:49:47 | * | DAddYE joined #nimrod |
| 17:50:21 | dom96 | wouldn't it make more sense to reuse the TR macros syntax? string{const}? |
| 17:51:39 | zahary | actually, I think we should deprecate this particular piece of TR syntax. expr[T] is much more widely supported in the compiler |
| 17:52:14 | dom96 | actually doesn't string{const} already work for procedures? |
| 17:52:20 | zahary | and already used for generic parameters of types |
| 17:52:20 | zahary | type Foo[T; I: expr[int]] |
| 17:52:49 | zahary | It misses the "instantiate the proc for each value like a generic" part |
| 17:53:05 | zahary | works for macros and templates properly tho |
| 17:53:05 | ehaliewicz | actually i'm not sure why my client joined this channel automatically |
| 17:53:05 | EXetoC | "lib/system.nim(641, 39) Warning: unknown magic 'UnaryPlusF32' might crash the compiler [UnknownMagic]" hm |
| 17:53:08 | ehaliewicz | but i don't mind :) |
| 17:53:46 | EXetoC | I switched branch and then went back, and now I get this. doing 'koch clean' doesn't make a difference |
| 17:54:24 | dom96 | EXetoC: Recompile with your changes and that should go away. |
| 17:55:01 | zahary | EXetoC, hide the definition of the magic in system.nim behind ``when not defined("booting"): `` |
| 17:55:37 | zahary | this way, it won't be visible for the compiler itself, but you are testing it only in user code anyway |
| 17:58:24 | EXetoC | thanks |
| 17:59:54 | EXetoC | "Error: cannot instantiate TV2 got: (typedesc[T]) but expected: (T)" |
| 18:00:05 | EXetoC | proc v2T*[T:TNumber](x, y: T = 0): TV2[T] = [x, y] |
| 18:00:12 | EXetoC | I'm not sure what changed in the compiler |
| 18:00:23 | zahary | this used to work? |
| 18:00:37 | zahary | trying it here |
| 18:00:56 | EXetoC | yes. is one of your recent commits of relevance? |
| 18:02:13 | zahary | could be, but it works for me |
| 18:04:13 | EXetoC | zahary: this too https://gist.github.com/EXetoC/e1082bb6e3dc5c660e38 ? |
| 18:04:40 | zahary | ok, this failed |
| 18:06:48 | zahary | I was debugging something similar yesterday so it could be related |
| 18:07:05 | EXetoC | ok |
| 18:07:30 | zahary | you could remove the constraint on TV2[T] if the code is important for you now |
| 18:07:34 | zahary | that seems to fix it |
| 18:10:47 | Mat2 | hmm, I can not access local variables from within a nested proc at same nesting level |
| 18:11:44 | Mat2 | I mean local variables from its enclosing scope |
| 18:12:02 | Mat2 | probably I must mark the proc as closure ?!?? |
| 18:15:17 | EXetoC | possibly |
| 18:16:12 | EXetoC | zahary: yup |
| 18:18:38 | Mat2 | I can cirqumvent this by pass var parameters instead (like in C) however, so it works |
| 18:19:11 | zahary | Mat2: can you post a gist? |
| 18:20:47 | Mat2 | sorry, what's a gist ? I can upload the sources to my repro |
| 18:22:27 | EXetoC | gist = github pastebin |
| 18:22:43 | EXetoC | but upload it wherever |
| 18:22:43 | Mat2 | ok, ono momento |
| 18:26:34 | Mat2 | https://gist.github.com/anonymous/6357167 |
| 18:29:09 | zahary | I don't see anything wrong with it. how does it fail? |
| 18:29:51 | Mat2 | it compiles but then I get these error: |
| 18:30:26 | zahary | the C compiler chokes on the code? |
| 18:30:40 | Mat2 | Fehler: »ob« nicht deklariert (erste Benutzung in dieser Funktion) |
| 18:30:45 | zahary | I think this happens when one closure captures another closure |
| 18:30:54 | zahary | you could try to produce a minimal test case and report a bug |
| 18:31:23 | zahary | see how `inRange` is used in the second closure |
| 18:31:54 | Mat2 | ah, I see |
| 18:32:23 | Mat2 | however, that should work so its definatly a bug |
| 18:32:53 | Mat2 | (in my opinion) |
| 18:33:27 | zahary | yes, sure, report it |
| 18:34:13 | Mat2 | ok, it take some moments |
| 18:37:42 | Mat2 | ehm, I need a working git account for an error report as I see... ok, this will take some moments in addition |
| 18:38:14 | EXetoC | "Error: internal error: genMagicExpr: mMulF32" Trying to figure out what I'm missing now |
| 18:38:47 | zahary | EXetoC, you should be using debug builds. they print a stack trace on such errors |
| 18:39:36 | EXetoC | I am. uploading now |
| 18:40:02 | zahary | I use this shell function when building most of the time |
| 18:40:02 | zahary | nimd-build () { |
| 18:40:02 | zahary | local PREVDIR=`pwd` |
| 18:40:02 | zahary | cd ~/Projects/nim |
| 18:40:02 | zahary | nimrod c -d:debug $* compiler/nimrod.nim && cp compiler/nimrod ./bin/nimd |
| 18:40:03 | zahary | cd $PREVDIR |
| 18:40:03 | zahary | } |
| 18:40:20 | zahary | it doesn't perform full bootstrap and creates a separate binary called nimd |
| 18:41:32 | dom96 | zahary: You should put that in koch it looks very useful. |
| 18:42:36 | zahary | it's more useful in your shell rc file, because you get to autocomplete it |
| 18:42:36 | zahary | ni[tab] ... |
| 18:43:08 | dom96 | wouldn't that conflict with 'nimrod'? :P |
| 18:44:02 | zahary | yeah, I do it pretty much unconsciously, have no idea what I'm actually pressing :) |
| 18:44:11 | EXetoC | https://gist.github.com/EXetoC/b923377ca0f65cd85bd7 |
| 18:44:53 | zahary | looks like your magic has slipped all the way to the code generator |
| 18:44:54 | EXetoC | "does the brain control you, or do you control the brain?" - Karl Pilkington |
| 18:44:55 | zahary | is this expected? |
| 18:45:20 | EXetoC | good question |
| 18:45:55 | zahary | there is arithmetic stuff there so probably yes |
| 18:45:55 | zahary | ccgexprs.nim(1601) genMagicExpr |
| 18:48:54 | Araq | zahary: string{lit} is no generic so the syntax makes sense |
| 18:49:09 | Araq | it's merely an AST constraint |
| 18:50:06 | zahary | well, what should happen when it's passed to a proc? the constness is lost |
| 18:50:26 | Araq | what do you mean? |
| 18:50:34 | Araq | proc p(x: string{lit}) |
| 18:50:38 | Araq | p "ha" # compiles |
| 18:50:45 | Araq | p someVar # does not |
| 18:51:06 | zahary | aha, I see. my point was that inside p x is no longer a known const value |
| 18:51:18 | Araq | yeah but that's not its purpose |
| 18:52:46 | EXetoC | zahary: what do I need to do? I don't have much bootstrapping experience |
| 18:53:16 | zahary | well, you are now at the point where you must generate C code for the operations you added |
| 18:54:53 | zahary | look at the top of genMagicExpr, all floats go to binaryFloatArith, which will just do something like (a + b) in the C code |
| 18:55:27 | zahary | you have to add your magics to the case expr in genMagicExpr so they will go through the same path |
| 18:55:48 | Mat2 | hi Araq |
| 18:56:26 | EXetoC | Missed that |
| 18:56:55 | Mat2 | Araq: please take a look at this: https://gist.github.com/anonymous/6357167 |
| 18:58:12 | reactormonk | Mat2, why pass fImm inside the function? |
| 18:59:57 | Mat2 | oh, I have forgot to delete it, thanks |
| 19:00:59 | Araq | Mat2: well? what should I look at in particular? |
| 19:01:29 | Araq | EXetoC: I told you not to introduce new magics; that's unnecessary and annoying ;-) |
| 19:01:56 | Mat2 | the closure do not compile if I try to access external variables in its scope |
| 19:02:42 | Mat2 | only if I make them explicite though passing as var parameters |
| 19:03:01 | Araq | you cannot capture 'var' parameters as that would break memory safety |
| 19:03:12 | Araq | so you need to pass them explicitly yes |
| 19:03:17 | Mat2 | ah ok |
| 19:03:31 | Araq | once the compiler is smart enough that you closures do not escape it can be allowed for this case |
| 19:03:54 | Mat2 | ok, then its a feature and not a bug |
| 19:04:50 | zahary | bug he got a C compilation error? my guess was that capturing a closure from another closure produces wrong code. I've stumbled on this in the compiler once I think |
| 19:05:09 | Mat2 | yes, I get a C compilation error |
| 19:05:20 | Araq | that's a bug then yeah |
| 19:06:10 | Araq | I don't know if I ever implemented capturing a closure from a closure but this should produce an internal error then, not a C compilation error |
| 19:06:17 | Mat2 | ok, filling a bug report afer 'reactivating' my old git account |
| 19:06:22 | Mat2 | ^after |
| 19:07:04 | EXetoC | Araq: well, it's there now. should I revert it? |
| 19:08:25 | zahary | https://github.com/Araq/Nimrod/issues/581 |
| 19:08:28 | Araq | EXetoC: yes please |
| 19:09:33 | Mat2 | zahary: Thanks, just get into my account this minute but you was faster :) |
| 19:12:58 | Mat2 | next test I should try to capture closures within closures recursive *g* |
| 19:19:45 | EXetoC | Araq: but what is there to edit in the format strings, if the existing ones are to be re-used? you don't mean binArithTab? |
| 19:21:16 | Araq | in binaryFloatArith |
| 19:21:36 | Araq | putIntoDest(p, d, e.typ, rfmt(nil, "($2 $1 $3)", |
| 19:21:37 | Araq | toRope(opr[m]), rdLoc(a), rdLoc(b))) |
| 19:21:40 | Araq | becomes: |
| 19:23:37 | Araq | putIntoDest(p, d, e.typ, rfmt(nil, "((NF$4)($2) $1 (NF$4)($3))", |
| 19:23:39 | Araq | toRope(opr[m]), rdLoc(a), rdLoc(b), (e[1].typ.size*8).toRope)) |
| 19:25:29 | Araq | or perhaps: getSimpleTypeDesc(p.module, e[1].typ) instead of the size*8 stuff |
| 19:25:41 | Araq | and then $4 instead of NF$4 |
| 19:26:07 | Araq | and then you need to use your brain and edit the table in binaryArith accordingly |
| 19:26:57 | EXetoC | good advice |
| 19:27:38 | EXetoC | I ususally have my brain on standby |
| 19:28:03 | Araq | sorry but in my experience people stop using it when they get help from me :P |
| 19:31:10 | reactormonk | ^ true. |
| 19:34:52 | Araq | EXetoC: in the longer run I want to get rid of mSubI vs mSubI64 too, it doesn't help anyway |
| 19:36:45 | EXetoC | they seem to be mostly just grouped together, so I guess I can manage that |
| 19:37:35 | Araq | you can also change |
| 19:37:37 | Araq | "($1 + $2)", # AddF64 |
| 19:37:39 | Araq | to |
| 19:37:47 | Araq | mAddF64: "....", |
| 19:37:56 | Araq | since the compiler now supports that :P |
| 19:40:03 | EXetoC | that's useful |
| 19:41:15 | EXetoC | is the difference just syntactical? |
| 19:41:30 | Araq | yeah |
| 19:42:16 | Araq | circ-user-6tksC I've implemented 'mixin' in a branch that I will merge soon, it's only about symbol binding rules in templates |
| 19:42:44 | Araq | it has nothing to do with OO mixins |
| 19:46:36 | circ-user-6tksC | Thanks, Araq. So what kind of plan do you have to implement the "more expressive type constraints" mentioned in http://forum.nimrod-code.org/t/145. COuld you talk a little more on this? |
| 19:47:06 | Araq | no because zahary already did: http://forum.nimrod-code.org/t/208 |
| 19:49:13 | circ-user-6tksC | Got it. I guess I got what I am looking for. Thanks again Araq |
| 19:53:49 | Mat2 | ciao |
| 19:54:03 | * | Mat2 quit (Quit: Verlassend) |
| 20:26:07 | * | gradha joined #nimrod |
| 20:29:39 | * | circ-user-6tksC quit (Remote host closed the connection) |
| 20:33:53 | * | uuu quit (Ping timeout: 245 seconds) |
| 20:42:42 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 20:45:06 | * | EXetoC joined #nimrod |
| 20:45:49 | Araq | so ... if html 5 only needs <!DOCTYPE html>, does it still need a <?xml ...> ? I guess not ... |
| 20:48:10 | gradha | are you working now on the js backend? |
| 20:51:21 | Araq | no. why? it should work flawlessly |
| 20:52:45 | gradha | so you are writing html by hand? that would be like, writing C code |
| 20:53:04 | Araq | no I'm writing a custom nimdoc.cfg for my slides |
| 20:54:57 | Araq | works pretty well in fact, can't believe I tried LaTeX again |
| 20:55:23 | dom96 | Araq: No it does not. HTML5 is not XHTML :P |
| 20:55:39 | gradha | if I were to write some PDFs I would try lout first, it seems obscure enough to be worth of interest |
| 20:56:13 | Araq | I figured that I need to make slides and not a PDF :P |
| 20:57:03 | gradha | will you publish the html too? people usually end up with a PDF containing a slide per page |
| 20:57:25 | Araq | well I'm not using Latex so I only got the HTML |
| 20:57:47 | Araq | I'm using "nimrod rst2html" of course |
| 20:57:56 | Araq | everything else would be insane |
| 20:59:13 | gradha | in my previous life as a python developer I had great success using http://www.reportlab.com for pdf generation |
| 21:00:46 | gradha | it's BSD http://www.reportlab.com/software/opensource/rl-toolkit/faq/ so I was going to look at some point if there was any C core which could be wrapped in nimrod |
| 21:02:52 | Araq | you mean the doc generator should generate PDF directly instead of a .tex file? crazy idea ... :-) |
| 21:49:33 | * | OrionPK joined #nimrod |
| 21:54:12 | * | fowl joined #nimrod |
| 22:14:52 | EXetoC | Araq: I tried to change the signature of <= "proc `<=` *[T:TReal](x, y: T): bool", but then it can't be called with (int, float) for example, which you could before. |
| 22:15:02 | EXetoC | so I guess I might need to define multiple functions |
| 22:16:44 | * | io2 quit () |
| 22:16:47 | Araq | EXetoC: yeah |
| 22:29:15 | EXetoC | Araq: "proc `-=`*[T: float|float32|float64] (x: var T, y: T)" this is a slightly different interface though. is that intended? |
| 22:30:31 | Araq | ask zahary; I don't think so, I think it's a bug |
| 22:31:04 | gradha | so I did use ouroboros in the compiler but it's not working, it's not parsing correctly the imported modules |
| 22:31:22 | Araq | gradha: cool. what's the problem? |
| 22:31:30 | gradha | is it ok to open the parser like https://github.com/gradha/Nimrod/commit/d055c6a52ded3c949a982394b6067e79ee574b86#L12R54 |
| 22:31:45 | gradha | maybe OpenParsers wasn't meant to be passed a string |
| 22:32:18 | gradha | after all it tries to open a pipe file or something like that |
| 22:33:25 | gradha | my feeling is syntaxes.openParsers should check the type of the inputStream and not call parsePipe, maybe do something else? |
| 22:34:27 | Araq | well your usage of openParsers looks correct |
| 22:34:39 | EXetoC | float is a little more special than a simple alias, so it's getting a little tricky for that reason |
| 22:34:42 | EXetoC | lib/system/arithm.nim(93, 10) Error: ambiguous call; both system.*(x: float64, y: float64): float64 and system.*(x: float, y: float): float match for: (float, float64) |
| 22:35:57 | Araq | you added * for float64 too? |
| 22:36:40 | EXetoC | I got an error, so I tried to fix it. actually, I only have overloads for float32 and float64 atm, so I'm not sure what's going on |
| 22:37:01 | Araq | well system defines things for 'float' too I'm sure |
| 22:37:20 | Araq | or did you remove these? |
| 22:39:11 | gradha | Araq: is there any debug proc to log a PNode and its descendants? I could at least compare a normal run to one with ouroboros and verify the trees are the same |
| 22:39:33 | Araq | debug(n) does the trick |
| 22:39:36 | EXetoC | no they're there |
| 22:40:03 | Araq | EXetoC: well then the error is perfectly clear and you should remove * for float64 |
| 22:40:04 | EXetoC | overloads for all float types |
| 22:41:17 | Araq | however ... I think vector3000 might be right and "float" should always been an alias to either float64 or float32 ... |
| 22:42:47 | EXetoC | D for example has real, which is sometimes 80 bits IIRC |
| 22:42:55 | EXetoC | lib/system/arithm.nim(79, 24) Error: ambiguous call; both system.*(x: float32, y: float32): float32 and system.*(x: float, y: float): float match for: (float64, BiggestFloat) |
| 22:43:05 | EXetoC | nevermind that |
| 22:43:13 | EXetoC | I thought I recompiled and all.. |
| 22:45:25 | EXetoC | no, I removed the overloads for float64 like you said |
| 22:45:31 | gradha | ah, it's failing because I have to patch include now too |
| 22:46:04 | * | profmakx quit (Ping timeout: 264 seconds) |
| 22:46:09 | Araq | gradha: why not patch llstreams instead? |
| 22:47:05 | Araq | btw wb DAddYE |
| 22:47:09 | gradha | hmm... could try that |
| 22:47:20 | DAddYE | ? |
| 22:47:44 | Araq | by the way, welcome back |
| 22:48:01 | sinistersnare | Araq: many hours ago you said something about building packages |
| 22:48:13 | sinistersnare | i meant that there should be a nimrod package |
| 22:48:15 | EXetoC | so the float32 overload shouldn't be considered. implicit conversion to a smaller type is a bad idea |
| 22:48:17 | sinistersnare | 'sudo apt-get install nimrod' |
| 22:48:18 | DAddYE | Araq: hahahah yeaaaa! Got a vacation !!! |
| 22:48:25 | gradha | Araq: I can patch LLStreamOpen when it accepts a filename, but there are others using var TFile, wouldn't I need to track those down? |
| 22:48:26 | DAddYE | Back from Italy + NY |
| 22:49:08 | Araq | sinistersnare: that's not our business, that's the business of a package manager |
| 22:49:36 | Araq | gradha: good point |
| 22:49:41 | sinistersnare | Araq: do you mean that its the job of someone else to get our stuff put into a distribution for us (that sounded a lot more condescending than i intended) |
| 22:50:22 | Araq | well it's certainly not my job because I couldn't care less ;-) |
| 22:50:55 | sinistersnare | oh sure |
| 22:51:14 | sinistersnare | i know nothing about building packages, i just thought that it was interesting that there wasnt a package for it :p |
| 22:51:25 | sinistersnare | windows had a installer, but i had to build nimrod from source for *nix |
| 22:51:29 | gradha | sinistersnare: would you be ok with downloading a binary for the compiler from the nimrod site? |
| 22:51:36 | sinistersnare | gradha: yes |
| 22:51:38 | Araq | sinistersnare: we also still lack a wikipedia page :P |
| 22:51:48 | sinistersnare | yeah i noticed that too! |
| 22:52:36 | gradha | sinistersnare: I'm working on http://forum.nimrod-code.org/t/194 now, so if I get it to work we could in theory provide a single binary for common platforms ready to use |
| 22:53:25 | sinistersnare | oh cool |
| 22:53:31 | sinistersnare | well that sounds fun |
| 22:54:43 | Araq | gradha: doesn't help, deploying binaries on Linux is a mess |
| 22:55:13 | sinistersnare | i wouldnt know, im a linux newbie, so i dont have much to help. but ive been using linux and was surprised there wasnt a package |
| 22:55:19 | gradha | like, wget url && chmod compiler && ./compiler ? |
| 22:55:21 | sinistersnare | because it seems there is a package for everything! |
| 22:56:25 | * | profmakx joined #nimrod |
| 22:56:41 | * | profmakx quit (Changing host) |
| 22:56:41 | * | profmakx joined #nimrod |
| 22:57:23 | Araq | sinistersnare: depends on your distribution some do have nimrod |
| 22:57:28 | gradha | maybe the problem with linux binaries is the "oh, if it's not source it's bad" mentality? |
| 22:58:09 | Araq | gradha: yes. It's also the reason why there is very few commercial software for Linux. |
| 22:58:11 | sinistersnare | linuxmint, which includes ubuntu and debian repos |
| 22:58:47 | sinistersnare | Araq: i disagree with that, i think that its because adoption has been relatively low, but there has been a rise in adoption lately |
| 22:58:52 | sinistersnare | with things like steam coming to linux |
| 22:58:56 | gradha | ok, will have to distribute nimrod through Steam |
| 22:59:00 | sinistersnare | lol |
| 22:59:09 | gradha | and charge a fee, of course |
| 22:59:20 | Araq | sinistersnare: that's what people say since the 90ies |
| 22:59:31 | sinistersnare | i wasnt alive for most of the nineties :p |
| 22:59:34 | sinistersnare | i wouldnt know! |
| 22:59:48 | gradha | we were using steam in the 90ies before it was mainstream |
| 22:59:52 | EXetoC | gradha: if the source is proprietary you mean? |
| 23:00:13 | EXetoC | because many distros provide binary packages |
| 23:00:38 | gradha | maybe if there is a single linux binary binary distro packages will be easier to make? |
| 23:00:57 | gradha | after all, you just have to put the thing somewhere and see it doesn't coredump |
| 23:01:59 | sinistersnare | well there are single linux binaries IIRC, its just that there are different package formats |
| 23:07:27 | EXetoC | Araq: so I don't know how to continue since float32 and float are prioritized the same when passing float64 |
| 23:13:52 | Araq | EXetoC: sigmatch.nim, proc handleFloatRange deals with overloading resolution for floats |
| 23:14:25 | Araq | you could disallow implicit conversions to float32 here |
| 23:26:28 | * | ltbarcly_ quit (Read error: Operation timed out) |
| 23:33:28 | Araq | good night |
| 23:33:36 | gradha | bye |
| 23:35:04 | EXetoC | don't I need to determine what 'float' really is in this case? |
| 23:36:40 | EXetoC | or I could just assume that it's float64.. |
| 23:39:30 | * | fowl quit (Remote host closed the connection) |
| 23:44:32 | EXetoC | that's not so bad |
| 23:45:53 | EXetoC | temporary solution of course |
| 23:52:29 | * | sinistersnare quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 23:57:05 | * | the_hoser joined #nimrod |
| 23:57:43 | * | sinistersnare joined #nimrod |