| 00:05:16 | Joe_knock | You guys saw this: https://news.ycombinator.com/item?id=7959217 I was trying to do a site-specific search in DDG but this popped up somehow |
| 00:08:26 | Araq | "Also, my language does not rely on GC, instead using annotated pointer types to get deterministic memory management (without requiring very explicit allocation and deallocation)." |
| 00:08:35 | Araq | yeah yeah yeah |
| 00:09:43 | wan | it's there apparently: https://github.com/djc/runa |
| 00:13:25 | flaviu | What was the problem with Nim and gdb again? |
| 00:13:38 | flaviu | So far, it's working absolutely perfectly for me. |
| 00:15:22 | flaviu | No problems with name mangling or anything. |
| 00:15:27 | willwillson | was it something about confusing variable names? |
| 00:15:52 | flaviu | https://gist.github.com/flaviut/b7863486909471042000 |
| 00:16:20 | flaviu | willwillson: that's what I recall too, but it works fine for me. |
| 00:16:37 | Araq | locals are not mangled if we can avoid it |
| 00:16:47 | Araq | globals are and in particular function names |
| 00:17:10 | Araq | but still it's perfectly workable and most people simply never try |
| 00:17:24 | flaviu | functions look good to me: https://gist.github.com/flaviut/ef97dccb48f2e7dfd7ca |
| 00:17:49 | flaviu | the trailing number doesn't really ruin anything. |
| 00:19:56 | Araq | well yeah but try to output a bit set of an enum for instance |
| 00:20:07 | Araq | we need pretty printers for GDB |
| 00:20:30 | Joe_knock | darn, I feel lost getting this app up :-/ |
| 00:20:34 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 00:20:41 | flaviu | ah. I'm also having trouble dumping globals, a bunch of strings and functions |
| 00:20:41 | ldlework | I don't know how to use gdb |
| 00:21:12 | flaviu | ldlework: Nether do I. I found a cheat sheet on the internet though, it's pretty easy. |
| 00:21:47 | * | vendethiel joined #nimrod |
| 00:22:28 | Joe_knock | onionhammer: This is how I'm initializing my sqlite DB: https://pastee.org/uab8d |
| 00:25:49 | flaviu | Huh. It thinks that one of my globals is located in `nimlang/lib/system/gc.nim`. |
| 00:26:06 | flaviu | Anyone have any idea what might make GDB think that? |
| 00:27:42 | Araq | the gc uses a variable of the same name? |
| 00:27:51 | Araq | gdb simply lists everything |
| 00:28:18 | flaviu | Not a chance, test123 is pretty unique |
| 00:28:28 | flaviu | and the value is the same as what I gave it |
| 00:29:12 | flaviu | https://gist.github.com/flaviut/344d3e59a507d1fd6412 |
| 00:29:54 | Araq | dunno, report it |
| 00:29:57 | Araq | good night |
| 00:30:02 | flaviu | ok |
| 00:30:04 | flaviu | night |
| 00:45:05 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 00:47:28 | * | vendethiel joined #nimrod |
| 01:00:18 | ldlework | hmm I can't find an absolute value function |
| 01:00:39 | ldlework | oh system |
| 01:08:38 | ldlework | hey guys is there a way to like.. run some code to generate some data at compile time so I can access it during runtime? |
| 01:09:20 | flaviu | ldlework: http://nimrod-lang.org/manual.html#static-statement-expression |
| 01:10:29 | flaviu | I think that will work, but on second thought, just do `const myData = myGenerator()` |
| 01:11:05 | * | johnsoft quit (Read error: Connection reset by peer) |
| 01:12:19 | ldlework | flaviu: is that a macro? |
| 01:12:36 | flaviu | no, myGenerator is just a normal proc |
| 01:12:56 | ldlework | that calculates it at compile time? |
| 01:13:08 | * | BitPuffin joined #nimrod |
| 01:13:18 | ldlework | I guess consts are determined then, so yeah |
| 01:13:20 | ldlework | ok |
| 01:13:23 | flaviu | the `const` says that it must calculate at compile time |
| 01:13:30 | EXetoC | but it doesn't work with objects yet |
| 01:13:45 | ldlework | EXetoC: but it does with arrays? |
| 01:14:24 | EXetoC | it should |
| 01:16:08 | ldlework | Will Nim let me do, proc circlePoints(r, n): array[n, int] = |
| 01:16:49 | flaviu | ldlework: Is there a specific reason you need this at compile-time? |
| 01:16:59 | EXetoC | that should work if 'n' is a compile-time value |
| 01:17:11 | ldlework | flaviu: I just told people I computed the points of a circle at compile time lol |
| 01:17:21 | EXetoC | which it can be in this case because of lack of typing I think |
| 01:17:24 | ldlework | EXetoC: since I will call this function to generate a const array, yes |
| 01:17:34 | EXetoC | well |
| 01:17:56 | EXetoC | or maybe you'd need static[T] instead |
| 01:19:17 | flaviu | Yep, static[t] |
| 01:19:42 | * | johnsoft joined #nimrod |
| 01:19:43 | EXetoC | but aren't those two parameters of type 'expr'? or is it auto? |
| 01:20:06 | EXetoC | oh right, "auto* = expr" |
| 01:24:47 | flaviu | ldlework: https://gist.github.com/d8472481c35d6d81173c |
| 01:25:04 | ldlework | that's awesome |
| 01:25:12 | * | Joe_knock quit (Quit: Leaving) |
| 01:25:23 | ldlework | I didn't think seq would work at compiletime |
| 01:25:30 | flaviu | But it does! |
| 01:25:47 | EXetoC | indeeeed |
| 01:28:10 | flaviu | If they want more proof, you can `const circleData = $circle(1, 50)` and `strings` on the output executable |
| 01:28:51 | willwillson | or show them the generated c ;-) |
| 01:29:08 | flaviu | Good point |
| 01:29:58 | willwillson | that is pretty cool though, I wouldn't have guessed it worked with seqs either |
| 01:32:18 | EXetoC | we do have a nice VM |
| 01:33:58 | flaviu | EXetoC: Your happy feeling will rapidly dissipate once you start using it :( |
| 01:34:00 | flaviu | https://github.com/Araq/Nimrod/issues?q=is%3Aopen+is%3Aissue+label%3AVM |
| 01:36:56 | EXetoC | oh well |
| 01:45:03 | EXetoC | I'm trying to create a template for mapping enumerators to types, but it's tricky |
| 01:49:01 | ldlework | EXetoC: like this, https://github.com/Araq/Nimrod/blob/devel/lib/wrappers/sdl/sdl.nim#L1285 ? |
| 01:49:35 | ldlework | oh that's not the same thing |
| 01:49:37 | ldlework | sorry |
| 01:50:38 | * | q66 quit (Quit: Leaving) |
| 01:50:43 | EXetoC | template toType(e: static[Enum]): typedesc = ??? |
| 01:55:37 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 02:00:30 | willwillson | EXetoC: template toType(a: enum): typedesc = a.type ? |
| 02:00:56 | * | vendethiel joined #nimrod |
| 02:03:58 | EXetoC | template toType(e: static[Enum]): typedesc = case e: of bla: float32... |
| 02:05:59 | EXetoC | I'll get back to that some other time |
| 02:09:44 | * | Demos joined #nimrod |
| 02:10:21 | willwillson | did you try using when instead of case? what didn't work by the way? |
| 02:13:53 | EXetoC | willwillson: thanks, I forgot |
| 02:13:59 | EXetoC | works now |
| 02:14:02 | willwillson | sweet |
| 02:14:15 | ldlework | EXetoC: make sure to show us! |
| 02:17:00 | EXetoC | damn right I will :p |
| 02:20:05 | willwillson | is d:useFFI (when bootstrapping) currently broken? |
| 02:20:40 | flaviu | willwillson: I think it's been broken for a while now |
| 02:20:58 | flaviu | IIRC It's too much work to support |
| 02:21:07 | willwillson | flaviu: thanks, I've been trying to get your circle example to work :D |
| 02:21:22 | willwillson | thought you might need to enable that for sin/cos |
| 02:21:26 | flaviu | Works for me, can you post your error? |
| 02:21:59 | willwillson | /tmp/aporia/a17.nim(7, 17) Error: cannot 'importc' variable at compile time |
| 02:22:36 | willwillson | my nim is a little old, might take it as an opportunity to recompile :D |
| 02:22:49 | flaviu | yep, that's probably it. |
| 02:22:59 | ldlework | wtf... |
| 02:23:16 | ldlework | dx = self.ctl.display.w - 1 |
| 02:23:34 | ldlework | automata.nim(93, 28) Error: type mismatch: got (range -1..9223372036854775806(int)) but expected 'int32' |
| 02:23:41 | ldlework | display is a graphics.PSurface |
| 02:23:52 | ldlework | its .w is definitely an int |
| 02:25:36 | ldlework | Well |
| 02:25:38 | ldlework | they are Natural |
| 02:25:42 | ldlework | what is that |
| 02:25:42 | EXetoC | cint? |
| 02:25:47 | EXetoC | oh |
| 02:25:57 | flaviu | ldlework: It means the compiler proves that it never becomes negative |
| 02:26:00 | EXetoC | range[0..high(int)]. again in system |
| 02:26:42 | flaviu | So if w = 0, then that - 1 would break the contract |
| 02:27:04 | ldlework | :( more type annotations |
| 02:27:11 | * | darkf joined #nimrod |
| 02:51:51 | * | brson quit (Quit: leaving) |
| 03:04:26 | willwillson | that importc error seems to occur when you use koch install |
| 03:11:15 | * | perturbation quit (Quit: Leaving) |
| 03:14:57 | * | willwillson quit (Read error: Connection reset by peer) |
| 03:31:41 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 03:52:37 | * | flaviu quit (Ping timeout: 252 seconds) |
| 04:12:32 | fowl | ldlework, graphics module is not very useful fyi |
| 04:12:44 | fowl | you can do the same stuff with sdls gfx addon |
| 04:13:07 | ldlework | fowl: I think that it implements [] and such that makes it useful |
| 04:14:19 | ldlework | I mean, it is nice to have this right in the stdlib, https://gist.github.com/anonymous/b3154d66744e02462a00 |
| 04:15:38 | fowl | if you dont mind using surf.s everywhere |
| 04:15:50 | fowl | that example could be done with converters though |
| 04:15:57 | ldlework | converters? |
| 04:16:10 | fowl | converter for colors.TColor -> int32 (or w/e type sdl uses for color) |
| 04:16:48 | ldlework | but what do you mean by converter? |
| 04:17:16 | fowl | hold on |
| 04:17:27 | fowl | apparently theres only one example in the manual: http://build.nimrod-lang.org/docs/manual.html#convertible-relation (third code block) |
| 04:18:13 | ldlework | y'know |
| 04:18:19 | fowl | and no examples in either tutorial |
| 04:18:24 | ldlework | nim doesn't seem to implicitly convert int's to int32 |
| 04:18:30 | ldlework | even though this says it would |
| 04:18:31 | fowl | no |
| 04:18:38 | fowl | for you maybe |
| 04:18:44 | fowl | my int is int64 |
| 04:18:48 | ldlework | yeah mine too |
| 04:19:04 | ldlework | and sdl wants 32 |
| 04:19:10 | ldlework | and its a pain typing int32 everywhere |
| 04:20:15 | fowl | ioh i see what you mean |
| 04:46:27 | * | saml_ joined #nimrod |
| 04:47:59 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 04:51:13 | * | vendethiel joined #nimrod |
| 04:58:17 | * | brson joined #nimrod |
| 05:05:17 | * | darkf_ joined #nimrod |
| 05:07:00 | * | darkf quit (Ping timeout: 258 seconds) |
| 05:10:25 | * | darkf joined #nimrod |
| 05:13:08 | * | darkf_ quit (Ping timeout: 258 seconds) |
| 05:14:47 | * | BlaXpirit joined #nimrod |
| 05:19:01 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 05:22:42 | * | vendethiel joined #nimrod |
| 05:43:45 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 05:45:49 | * | vendethiel joined #nimrod |
| 06:01:01 | * | Demos quit (Ping timeout: 255 seconds) |
| 06:07:05 | * | Demos joined #nimrod |
| 06:19:19 | * | bjz joined #nimrod |
| 06:42:52 | * | brson quit (Ping timeout: 265 seconds) |
| 06:44:13 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 06:46:45 | Demos | it is worth the pain of typing int everywhere |
| 06:46:52 | Demos | narrowing conversions are bad |
| 06:47:35 | * | Demos quit (Read error: Connection reset by peer) |
| 06:50:07 | * | vendethiel joined #nimrod |
| 06:52:24 | * | saml_ quit (Quit: Leaving) |
| 07:05:08 | ldlework | is what worth it I wonder |
| 07:08:26 | * | gokr_ joined #nimrod |
| 07:12:34 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 07:14:13 | * | vendethiel joined #nimrod |
| 07:21:37 | * | AFKMorpork is now known as AMorpork |
| 07:27:52 | * | bjz_ joined #nimrod |
| 07:29:37 | * | bjz quit (Ping timeout: 264 seconds) |
| 07:34:52 | * | BlaXpirit quit (Ping timeout: 244 seconds) |
| 07:36:00 | * | gokr joined #nimrod |
| 07:36:00 | * | gokr_ quit (Read error: Connection reset by peer) |
| 07:54:03 | * | dain_ joined #nimrod |
| 08:00:57 | * | gokr_ joined #nimrod |
| 08:03:17 | * | gokr quit (Ping timeout: 240 seconds) |
| 08:13:52 | * | Boscop quit (Quit: Boscop) |
| 08:17:59 | * | dain_ quit (Quit: dain_) |
| 08:41:06 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 08:45:17 | * | vendethiel joined #nimrod |
| 08:51:38 | * | gokr joined #nimrod |
| 09:06:59 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 09:08:44 | * | vendethiel joined #nimrod |
| 09:25:26 | * | Trustable joined #nimrod |
| 09:48:13 | * | gour_ joined #nimrod |
| 09:49:55 | * | gour_ is now known as gour |
| 10:11:03 | * | q66 joined #nimrod |
| 10:30:53 | * | BitPuffin joined #nimrod |
| 10:36:06 | * | q66 quit (Quit: Leaving) |
| 10:53:43 | * | EXetoC quit (Remote host closed the connection) |
| 11:08:03 | * | Matthias247 joined #nimrod |
| 11:11:57 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 11:29:59 | * | Jehan_ joined #nimrod |
| 11:31:44 | * | flaviu joined #nimrod |
| 11:39:37 | * | Jehan_ quit (Quit: Leaving) |
| 11:50:27 | * | BlaXpirit joined #nimrod |
| 11:51:42 | * | yeye123 joined #nimrod |
| 11:52:08 | * | Jehan_ joined #nimrod |
| 11:54:41 | * | flaviu quit (Ping timeout: 250 seconds) |
| 12:07:51 | * | gokr quit (Quit: Leaving.) |
| 12:07:52 | * | gokr1 joined #nimrod |
| 12:39:09 | * | Jehan_ quit (Read error: No route to host) |
| 12:39:20 | * | Jehan_ joined #nimrod |
| 12:46:16 | * | BitPuffin joined #nimrod |
| 12:50:17 | * | dom96_ quit (Ping timeout: 245 seconds) |
| 12:52:34 | * | yeye123 left #nimrod ("Leaving") |
| 12:53:13 | * | khmm joined #nimrod |
| 12:59:54 | * | khmm quit (Ping timeout: 264 seconds) |
| 13:00:52 | * | Araq0 joined #nimrod |
| 13:04:12 | * | khmm joined #nimrod |
| 13:04:55 | * | Joe_knock joined #nimrod |
| 13:08:25 | * | Boscop joined #nimrod |
| 13:24:52 | * | untitaker quit (Ping timeout: 245 seconds) |
| 13:26:33 | Araq0 | ping Jehan_ |
| 13:26:42 | Jehan_ | Yes? |
| 13:28:01 | Araq0 | any opinion on our release schedule? |
| 13:29:14 | Jehan_ | Umm, I've only been skimming the forums. By release schedule I take it you mean 1.0 by the end of the year? |
| 13:29:50 | Araq0 | yeah |
| 13:30:00 | Jehan_ | My main computer broke recently and I had some trouble with the replacement, which is why I've been fairly inactive the past couple of weeks. |
| 13:30:12 | Araq0 | whether it's 0.10.x or 1.0 or 1.0 RC 1 |
| 13:30:29 | Araq0 | whether 'generic' NEEDS to be in 1.0 |
| 13:30:50 | Jehan_ | I think "generic" is an optional feature at the moment. |
| 13:31:09 | Joe_knock | As somebody whos voice wont count as much as a core-contrib, I suggest we be more liberal with release numbers and not worry too much about them. Functionality over form |
| 13:31:12 | Jehan_ | I'd shoot for an RC and then make that as stable as possible. |
| 13:31:38 | Jehan_ | Joe_knock: well, 1.0 is sort of a big thing in terms of messaging. |
| 13:31:42 | * | untitaker joined #nimrod |
| 13:32:10 | gour | what about beta? |
| 13:32:13 | Jehan_ | My personal preference would be to hide the unstable stuff behind an experimental switch and focus on bug fixing for the rest. |
| 13:32:29 | Araq0 | Jehan_: already implemented, but not pushed ;-) |
| 13:32:52 | Jehan_ | Araq0: Yeah, I saw it on the forums. |
| 13:33:23 | Jehan_ | So what I guess I'm saying is that I agree with your rationale. :) |
| 13:33:53 | Jehan_ | About the proposed changes: The only thing that I *might* do differently is choose a different name for "bnot" |
| 13:33:57 | * | gour is reading forum's thread |
| 13:34:26 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 13:36:27 | Araq0 | gour: for me 1.0.*0* is a beta anyway, but I dislike these semantic additions to version numbers |
| 13:36:48 | Jehan_ | Oh, I'm not sure about getting rid of the standalone except, but I'm really not invested in it either way, so, whatever. |
| 13:37:28 | gour | Araq0: it's of, of course, your choise. my idea is thar i consider 1.0beta is more suitable than 0.10.x |
| 13:37:40 | Araq0 | so what's the versioning scheme? 1.0.0 RC 1, RC 2 ... ? why not 1.0.0, 1.0.2 ? |
| 13:37:54 | Araq0 | why not use the numbers? |
| 13:38:20 | Jehan_ | *shrug* Basically, 1.0 RC1 ... RCn allows a hype cycle to be built up. |
| 13:38:45 | Jehan_ | You get people excited about stuff, but still have an excuse for something not quite working. |
| 13:38:57 | * | drewsrem joined #nimrod |
| 13:39:06 | Jehan_ | Granted, it's a somewhat mercenary perspective. |
| 13:40:31 | gour | Araq0: you can see from e.g. KDE's example with 4.0...i gree with Jehan_ |
| 13:40:35 | * | vendethiel joined #nimrod |
| 13:41:26 | Joe_knock | So let's do major/minor then. For minor releases, we can target level 3 version number changes. Eg. 1.1.0 ; 1.1.1; 1.1.2 |
| 13:41:40 | Joe_knock | For major changes: 1.1 ; 1.2 ; 1.3 |
| 13:42:10 | Joe_knock | And for compiler-based changes, we can jump to 2.0 ? |
| 13:43:33 | * | EXetoC joined #nimrod |
| 13:44:13 | gour | not being familiar with much of things which are going on, i also agree with dom96's " Because a 1.0 release is a very big deal, it will lock everything down so we need to make sure that what is in the language is what we want to be in the language." |
| 13:44:46 | Araq0 | but that's what I'm doing for months |
| 13:44:54 | Araq0 | fixing bugs and cleaning up things |
| 13:45:12 | gour | so, you believe that the language is ready spec-wise? |
| 13:45:25 | Araq0 | yeah |
| 13:46:15 | gour | then i'm for 1.0...go also did something similar, right? |
| 13:49:54 | gour | just don't forget that 1.0 can vbe done only once ;) |
| 13:51:12 | Araq0 | Jehan_: well we can do the full and-> &, or -> |, etc renamings |
| 13:51:41 | Jehan_ | Umm, not sure if I want the entire C operator salad ... |
| 13:51:47 | Araq0 | and then of course we need not also << and >> and <<= and >>= too |
| 13:52:07 | Araq0 | and of course << has a different precedence than C's |
| 13:52:33 | Araq0 | as usual it never ends |
| 13:53:32 | Araq0 | not -> bnot is the best solution IMO simply because it just fixes 1 problem instead of introducing a whole lot of new problems at the same time |
| 13:53:34 | Jehan_ | I was more asking if there isn't a better name than "bnot" (there may not be one). |
| 13:53:46 | Araq0 | "bitnot"? |
| 13:54:02 | Jehan_ | If there was a short word for "complement", I'd take that. :) |
| 13:54:17 | Jehan_ | But "cpl" isn't an improvement over "bnot". |
| 13:54:30 | Araq0 | meh, "complement" is a noun |
| 13:54:34 | Araq0 | doesn't feel right |
| 13:54:46 | Jehan_ | As I said, I'm not sure if there is a better alternative. |
| 13:55:30 | Jehan_ | Can also be a verb. |
| 13:55:42 | Araq0 | oh yeah |
| 13:56:26 | Jehan_ | Anyhow, I have to take off for now. Talk to you later! |
| 13:56:42 | * | Jehan_ quit (Quit: Leaving) |
| 13:58:22 | Joe_knock | before releasing 1.0 . I have just 1 thing to say: "1.0 should be a stable release that is maintained for 6-12 months minimum" |
| 14:00:57 | Araq0 | Joe_knock: I cannot see why this wouldn't be the case |
| 14:01:46 | Araq0 | on the contrary this endless 0.9.x stuff means nobody feels responsible for keeping backwards compatibility seriously |
| 14:01:55 | Araq0 | *treating |
| 14:02:11 | Joe_knock | 1 thing that concerns me is maintenance. We're a small group and we can't have too many versions out in the wild. |
| 14:02:44 | Araq0 | the only problem is when you change too much, like we had to for the cs:partial stuff |
| 14:03:01 | Araq0 | then maintaining 2 branches becomes ever more painful |
| 14:06:49 | Joe_knock | So let's fight bugs until almost all of them (+95%) are resolved, run our build tests for the compiler + any other thing that creates a solid stable base and say : 1.0 is ready |
| 14:07:30 | Araq0 | that's 1 year away. |
| 14:07:37 | Araq0 | do the math yourself |
| 14:08:05 | Araq0 | ~240 open bugs (without the feature requests) |
| 14:08:21 | Araq0 | fixing bugs causes new problems (see the recent 'echo' regressions) |
| 14:08:54 | Joe_knock | Unless you're eager for a 1.0 , I don't see why we should carry that many bugs with it (especially medium-high ones). |
| 14:09:55 | Araq0 | by this logic there should have never been a single Nim release |
| 14:10:34 | Araq0 | do you think they release a new verson of GCC only when the bug count is at 0? |
| 14:11:03 | Araq0 | I know of no decently sized software project that does that |
| 14:11:16 | Joe_knock | fair point, we can keep a few bugs. however, everything high priority that is a bug shouldn't be in a stable release (especially very old bugs) |
| 14:11:40 | Araq0 | yeah, I still intend every high priority bug for 1.0 |
| 14:12:08 | Araq0 | *intend to fix |
| 14:12:31 | Joe_knock | in the end, the decision is yours and for guys like dom96, Jehan, flaviu, etc. |
| 14:17:02 | gokr1 | Hey guys |
| 14:17:16 | gokr1 | Been battling a cloud, so haven't followed. |
| 14:19:28 | gokr1 | Some obvious things to mention: For us Nimmers, it really is no big deal. We are already Nimmers. The next release will change the name to Nim - it could be expected that a bit more attention is given from Reddit etc, so new website in place, properly tested building from source, some neat articles etc are naturally important. |
| 14:20:07 | Araq0 | gokr1: that's the "obvious" way to do a release |
| 14:20:24 | Araq0 | but it's also the way to never release |
| 14:21:09 | gokr1 | And obviously, if we say 1.0 instead of 0.x - people are going to watch more closely. But... as long as we are prepared for it, and perhaps armed with a good release description - I am all for releasing :) |
| 14:21:39 | Araq0 | so how long should we wait until somebody even *starts* with updating the docgen to incorporate all these nice changes that are obvious for anybody? |
| 14:23:02 | gokr1 | The new website was ready, right? |
| 14:23:17 | Araq0 | no, it never was |
| 14:23:27 | Araq0 | the *design* was ready iirc |
| 14:23:54 | Araq0 | but it's not a big deal, I'll replace the logo and call it a day |
| 14:24:50 | gokr1 | Either way, I can try chip in but not sure where I can help best at this point. |
| 14:25:46 | gokr1 | I do agree with the fact that a "1.0" implies some kind of "this is what Nim is" statement. But I thought the language was fairly settled, right? |
| 14:26:10 | gokr1 | At least enough for a 1.0, right? |
| 14:26:40 | gokr1 | Everyone knows that 1.0.23 is the version without the bugs anyway :) |
| 14:26:49 | gokr1 | Only idiots use 1.0 |
| 14:27:01 | Araq0 | lol, yes. it is settled. |
| 14:27:17 | Araq0 | just look at the list of upcoming changes |
| 14:27:23 | Joe_knock | It is sometimes difficult to do many things when the core team is small |
| 14:27:32 | Araq0 | everybody thinks it's a big deal |
| 14:27:41 | Araq0 | but I implemented half of that list already |
| 14:28:02 | Araq0 | it's really minor stuff |
| 14:28:35 | gokr1 | I agree - feels like minor stuff. |
| 14:28:55 | Araq0 | hmmm I like zio_tom78's CSS improvement better than filwit's new docgen design |
| 14:29:06 | Joe_knock | ping dom96 |
| 14:31:36 | Araq0 | also ... I think how we write a module's documentation is not that good |
| 14:31:48 | Araq0 | and the tool itself is not that bad |
| 14:32:19 | Araq0 | module should really have long examples up front and not document what the proc signature already tells you |
| 14:32:41 | gokr1 | Yeah, examples rules. |
| 14:32:58 | Araq0 | so maybe the docgen is fine for 1.0 |
| 14:33:43 | Araq0 | JavaDoc is the obvious thing **not** to copy |
| 14:35:21 | * | gokr1 quit (Quit: Leaving.) |
| 14:35:23 | Araq0 | a redesign of the documentation does not have to be coupled with a major release anyway |
| 14:36:01 | Araq0 | I'd rather have incremental "releases" |
| 14:39:44 | Joe_knock | Should an SQLite DB be initialized in a proc or using a var? |
| 14:41:12 | EXetoC | it's up to you |
| 14:42:43 | EXetoC | but it seems like a good idea to do as much as possible in procs rather than in the module scope |
| 14:46:59 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 14:47:01 | Joe_knock | EXetoC: By using this example (which seems outdated), can I turn what is written there into a Jester to-do web-app? |
| 14:47:07 | Joe_knock | link: https://github.com/Araq/Nimrod/tree/devel/examples/cross_todo/nimrod_backend |
| 14:49:39 | * | vendethiel joined #nimrod |
| 14:54:55 | Araq0 | Joe_knock: I can't see why not |
| 14:57:37 | * | gour_ joined #nimrod |
| 15:00:38 | * | Araq0 quit (Quit: Page closed) |
| 15:01:10 | * | darkf quit (Ping timeout: 258 seconds) |
| 15:01:33 | * | gour quit (Ping timeout: 258 seconds) |
| 15:16:31 | * | gour_ is now known as gour |
| 15:18:20 | * | gour feels that it should be stressed more that 1.0 means that langauge-wise it's stable which, naturally, does not imply implementation |
| 15:19:31 | gour | just remember the disaster with D langauge where Andrei even published book and then they, afaik. continue shuffling with the *language* features |
| 15:20:57 | * | gokr_ quit (Read error: Connection reset by peer) |
| 15:21:04 | * | gokr_ joined #nimrod |
| 15:27:18 | * | dom96_ joined #nimrod |
| 15:27:31 | dom96_ | Joe_knock: what's up? |
| 15:30:20 | dom96_ | Araq: I bet people are still using 0.9.6. We still do not know what people will think of the recent changes to the case sensitivity rules. |
| 15:30:53 | dom96_ | And do you seriously want to release 1.0 with all this deprecated shit? |
| 15:31:18 | dom96_ | We should release 0.10. Then remove everything that is deprecated and release 1.0 |
| 15:36:27 | Joe_knock | dom96_: would you be keen on a 1 hour project where we flesh out a to-do application as an example app? |
| 15:36:57 | dom96_ | Sure. |
| 15:37:18 | dom96_ | Joe_knock: When can you do it? |
| 15:37:37 | dom96_ | I'll be in a lecture for the next ~3 hours. |
| 15:37:45 | dom96_ | But then I should be around. |
| 15:37:49 | Joe_knock | how about tonight? |
| 15:38:16 | Joe_knock | 8.30pm your time |
| 15:38:38 | dom96_ | sure. |
| 15:39:09 | Joe_knock | okay, I'll see you here at 8.30pm, maybe we can get another example webapp in as well. |
| 15:39:29 | dom96_ | Cool. |
| 15:39:34 | dom96_ | See you then. |
| 15:39:45 | dom96_ | I suppose I should finish off jester's new_async branch |
| 15:39:50 | dom96_ | and merge it into master |
| 15:54:55 | * | dts|pokeball joined #nimrod |
| 16:08:50 | * | gokr joined #nimrod |
| 16:08:51 | * | khmm quit (Ping timeout: 265 seconds) |
| 16:13:40 | * | dom96_ quit (Ping timeout: 246 seconds) |
| 16:18:09 | * | uran joined #nimrod |
| 16:21:33 | * | dom96_ joined #nimrod |
| 16:32:55 | * | uran quit (Ping timeout: 246 seconds) |
| 16:41:21 | * | mko joined #nimrod |
| 16:58:33 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 17:03:39 | ldlework | good morning |
| 17:07:22 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 17:13:37 | * | dts|pokeball quit (Ping timeout: 240 seconds) |
| 17:15:08 | * | vendethiel joined #nimrod |
| 17:21:52 | ldlework | dead in here |
| 17:30:47 | dom96 | hey ldlework |
| 17:30:54 | ldlework | hullo |
| 17:31:19 | dom96 | what's up? |
| 17:31:26 | ldlework | Glad it is the weekend |
| 17:32:28 | dom96 | same. |
| 17:32:42 | dom96 | What are you working on in Nim at the minute? |
| 17:34:13 | ldlework | dom96: I have been writing a little game library ontop of our sdl/graphics libraries just to get used to writing Nim and how to organize my code |
| 17:36:18 | ldlework | I know its not very useful for the project |
| 17:38:46 | dom96 | Nim libraries are just as important as the compiler itself. |
| 17:39:05 | dom96 | It's brilliant that you are writing one. |
| 17:39:07 | dom96 | brb |
| 17:39:08 | * | brson joined #nimrod |
| 17:40:51 | ldlework | I wish I could set the default int size to something other than my native size |
| 17:41:32 | EXetoC | using other types doesn't require much effort |
| 17:42:01 | EXetoC | 0i32 |
| 17:42:16 | ldlework | There are a lot of number literals in game code |
| 17:42:28 | ldlework | So it would be pretty nice conveience |
| 17:44:27 | * | willwillson joined #nimrod |
| 17:47:39 | * | Mat4 joined #nimrod |
| 17:47:49 | Mat4 | hello |
| 17:49:20 | EXetoC | hi |
| 17:49:38 | EXetoC | ldlework: yes, but with added confusion |
| 17:49:43 | EXetoC | and I assume you mean literals only |
| 17:50:04 | Mat4 | hi EXetoC |
| 17:50:26 | ldlework | EXetoC: for literals and int |
| 17:50:48 | Mat4 | have someone seen 'dts|pokeball' today ? |
| 17:50:49 | willwillson | hi Mat4, is today the day of the big release? |
| 17:51:01 | dom96 | back |
| 17:51:27 | willwillson | Mat4: he showed up irc earlier if i recall correctly |
| 17:52:01 | Mat4 | willwillson: I have uploaded my IL compiler work currently |
| 17:52:44 | willwillson | oh yeah, I see it, good work! |
| 17:53:08 | dom96 | I wonder how much safety these "strict" literals actually add. |
| 17:53:37 | dom96 | I would personally prefer if any number literal just worked for int, int64, int32, float etc. |
| 17:54:37 | EXetoC | ? |
| 17:55:00 | ldlework | EXetoC: the thing you're assigning to is already typed |
| 17:55:25 | ldlework | there is literally no difference between 0i32 and 0i64, except whether it happens to match the thing you're assigning to |
| 17:55:34 | ldlework | so why not just make it implicitly match? |
| 17:55:39 | EXetoC | var x = 0i32 |
| 17:55:49 | EXetoC | dom96: : yes but sometimes you need to instantiate a type parameter with a certain integer type |
| 17:55:58 | ldlework | EXetoC: he's talking about the typed cases, I'm sure |
| 17:56:24 | EXetoC | there's no need to do that then |
| 17:57:14 | ldlework | there is |
| 17:57:18 | ldlework | because sometimes if I'm calling a function |
| 17:57:21 | ldlework | which takes int32 |
| 17:57:26 | ldlework | and I just type 50 |
| 17:57:29 | ldlework | it complains |
| 17:57:35 | ldlework | and makes me explicitly type cast it |
| 17:57:59 | EXetoC | it doesn't complain for me |
| 17:58:48 | dom96 | Yes, and this goes against one of Nim's goals "expressiveness" |
| 17:58:49 | EXetoC | if they have indeed been literals then you must have stumbled upon a bug |
| 18:01:00 | dom96 | Appears EXetoC is correct. |
| 18:01:00 | EXetoC | either that or the literals have been outside the number range for said type |
| 18:01:26 | dom96 | I think we need a better error for the latter case. |
| 18:02:12 | EXetoC | dom96: as in, include the legal range? |
| 18:02:19 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 18:03:13 | dom96 | perhaps |
| 18:06:51 | EXetoC | I don't think it's needed. the error message could just be a little more explanatory, so as to not have people think that it's always necessary to use suffixes |
| 18:06:54 | * | milosn quit (Remote host closed the connection) |
| 18:07:18 | * | vendethiel joined #nimrod |
| 18:07:27 | EXetoC | but it's also something you'll learn about fairly quickly anyway |
| 18:08:19 | Mat4 | I miss a general type, something like 'any' |
| 18:09:31 | EXetoC | I think we discussed this before, and you didn't want to create an explicit variant type, right? |
| 18:12:44 | EXetoC | what are you trying to do? |
| 18:13:56 | Mat4 | ^a type which can be converted to every possible type |
| 18:14:17 | Mat4 | (the typeless type) |
| 18:16:00 | EXetoC | how is this different from a union or a byte buffer? |
| 18:18:27 | Joe_knock | in a Proc, eg. : proc yes(question: string): bool = .... What is this part doing ": bool =" ??? |
| 18:18:58 | dom96 | Joe_knock: return type is bool |
| 18:18:58 | EXetoC | it returns bool |
| 18:19:13 | EXetoC | "proc yes(question: string) =" returns void basically |
| 18:19:28 | dom96 | Mat4: Maybe you could marshal everything using the marshal module and then pass strings everywhere? |
| 18:19:37 | dom96 | Not very efficient but might work :P |
| 18:20:22 | Joe_knock | okay, so the ": int =" or ": str =" is specifying the return type |
| 18:20:48 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 18:20:49 | Mat4 | EXetoC: because assignment is always implicit for such types, this would be a more elegant alternative to an union |
| 18:21:00 | Mat4 | (in my opinion) |
| 18:21:01 | EXetoC | Joe_knock: = should be there regardless, unless it's a forward declaration (no body) |
| 18:21:32 | EXetoC | Mat4: well how large should it be then? |
| 18:22:05 | EXetoC | will the user decide and then hope it's big enough? |
| 18:22:14 | Mat4 | dom96: In this case I can use TCL ;) |
| 18:23:18 | dom96 | I found filwit's new docs design: http://reign-studios.net/philipwitte/nim/docs-lib.htm |
| 18:23:32 | Joe_knock | so if I am initializing my DB using a "void" proc, should I instead be using another type of proc that returns something for my global connection variable ? |
| 18:24:56 | * | vendethiel joined #nimrod |
| 18:24:59 | Mat4 | EXetoC: casting to the largest possible type would do |
| 18:25:07 | dom96 | Joe_knock: Possibly, yes. |
| 18:28:01 | EXetoC | Mat4: the largest of every available type? |
| 18:28:10 | Mat4 | yes |
| 18:28:44 | Mat4 | eg. the wrd width |
| 18:28:49 | Mat4 | ^word |
| 18:29:13 | EXetoC | are you refering to integer types now? |
| 18:30:16 | EXetoC | if not, then it must be larger than the word size, probably |
| 18:31:31 | Mat4 | unsure, floating point representations need then to be converted to fixpoint to fit (this means scaled) |
| 18:31:42 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 18:32:33 | Joe_knock | in a situation like this: "proc getTodo(conn: DbConnection, id: string)" In the first parameter, is DbConnection a keyword like string ? |
| 18:32:56 | Mat4 | some languages do this |
| 18:33:12 | EXetoC | it's the name of a type, and I don't think string is a keyword |
| 18:34:16 | Joe_knock | okay, okay . I think I see it now. I was actually referring to string as a type, just called it a keyword :-/ |
| 18:35:22 | EXetoC | Mat4: why not just cast? you can just create your own type and hide that if you want |
| 18:37:29 | EXetoC | oh ok just one word, but then some precision will be lost |
| 18:37:59 | Mat4 | that's the disadvantage |
| 18:40:09 | Joe_knock | 1 more question. Would there be a conflict if my named variable uses the same name as a parameter specified in my proc ? |
| 18:41:41 | Joe_knock | named variable = global var |
| 18:42:31 | EXetoC | I remember someone saying it won't, but don't do that anyway |
| 18:42:42 | EXetoC | at least make the first character lowercase |
| 18:43:39 | Joe_knock | I could literally name my parameter anything right? |
| 18:44:56 | EXetoC | kind of |
| 18:45:08 | * | q66[lap] quit (Ping timeout: 250 seconds) |
| 18:45:26 | Joe_knock | Let me give this a try. |
| 18:45:55 | ekarlso- | what's the fastest of nim / rust ? ^^ |
| 18:46:07 | EXetoC | not anything of course |
| 18:46:42 | ldlework | ekarlso-: in terms of programmer productivity? Nim. |
| 18:46:46 | EXetoC | can't start with underscores and can't be that of a keyword |
| 18:46:58 | ekarlso- | ldlework: :P |
| 18:48:02 | * | q66[lap] joined #nimrod |
| 18:49:12 | Mat4 | ekarIso-: in term of readability? Nim. |
| 18:49:27 | * | dom96 quit (Changing host) |
| 18:49:27 | * | dom96 joined #nimrod |
| 18:49:43 | ekarlso- | i really hope nim will pick up vs rust / go |
| 18:50:03 | ldlework | ekarlso-: go is here to stay for sure |
| 18:50:18 | ekarlso- | ldlework: aint they on diff levels though ?= |
| 18:50:34 | ldlework | ekarlso-: I'd say so. |
| 18:50:39 | NimBot | nim-lang/nimforum new_async 9b0d507 Dominik Picheta [+0 ±1 -0]: Better smiley positioning. Larger font size. |
| 18:50:41 | ldlework | Still, go isn't going anywhere. |
| 18:51:39 | Joe_knock | ekarlso-: Thanks for coming through. we generally have this discussion with newbies that drop by. Think of Go as Googles idea of solving IO-style issues on web servers. Think of Rust as the inbetween of C++ and Ruby and then you can see Nim as an alternative to C++ |
| 18:54:28 | ldlework | Rust inbetween C++ and Ruby???? |
| 18:56:10 | EXetoC | hm :p |
| 18:56:57 | Joe_knock | Well they're all in between somewhere there :P |
| 18:57:29 | ldlework | Joe_knock: I would say Rust and C++ are at the same level of system access and abstraction |
| 18:57:35 | Joe_knock | ekarlso-: Honestly, I don't see us picking up that much, unless we get a corporate sponsor (I'm looking at Yahoo) |
| 18:57:37 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 18:57:39 | NimBot | nim-lang/nimble master 42dcac2 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Manually checks out the branch/tag after git clone. |
| 18:57:39 | NimBot | nim-lang/nimble master a0fb2c1 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Improves cloning of git repositories. Refs #70. |
| 18:57:39 | NimBot | nim-lang/nimble master a778b0f Dominik Picheta [+0 ±1 -0]: Merge pull request #70 from gradha/pr_patches_irregular_git_clone_behaviour... 2 more lines |
| 18:57:41 | ldlework | Rust is simply implemented today, and has elements of modern language design |
| 18:57:47 | Mat4 | hmm, I've seen Rust more as a traditional C oriented development alternative for programmers which grows with C and now prefer it style but not it short comings |
| 18:57:49 | ldlework | It isn't anywhere close to Ruby in terms of how it works |
| 19:00:17 | NimBot | nim-lang/nimforum new_async e52d65c Miguel [+0 ±2 -0]: highlighting current post via CSS :hover pseudo-element |
| 19:00:17 | NimBot | nim-lang/nimforum new_async 9e57852 Dominik Picheta [+0 ±2 -0]: Merge pull request #32 from Leu-Gim/new_async... 2 more lines |
| 19:01:03 | * | milosn joined #nimrod |
| 19:02:23 | Joe_knock | Is this an error that needs to be raised concerning nimble? https://pastee.org/n7quw |
| 19:04:03 | EXetoC | I think it should be catched |
| 19:18:19 | ekarlso- | Joe_knock: try IBM :p |
| 19:32:59 | willwillson | ekarlso-: https://github.com/kostya/benchmarks/ has a few rust vs nimrod benchmarks |
| 19:36:42 | * | AMorpork is now known as AFKMorpork |
| 19:37:12 | * | q66 joined #nimrod |
| 19:38:18 | * | dts|pokeball joined #nimrod |
| 19:43:32 | * | Hakaslak joined #nimrod |
| 19:44:41 | * | Hakaslak quit (Client Quit) |
| 19:45:47 | * | Demos joined #nimrod |
| 19:50:13 | * | q66 quit (Quit: Leaving) |
| 19:50:34 | * | q66 joined #nimrod |
| 19:58:14 | * | AFKMorpork is now known as AMorpork |
| 20:10:04 | * | Stefan_Salewski joined #nimrod |
| 20:11:36 | Stefan_Salewski | Is hyphen not allowed in module import path like import /home/stefan/nim-glib/src/glib2 |
| 20:12:23 | Stefan_Salewski | I know that hyphen is not allowed in Nim identifiers, but thought it is ok for paths? |
| 20:12:37 | dom96 | try: import "/home/stefan/nim-glib/src/glib2" |
| 20:12:58 | Stefan_Salewski | Ah, thanks. |
| 20:15:30 | Araq | absolute paths are not the best idea in imports though |
| 20:15:48 | Stefan_Salewski | And one additional remark: Beginners may type something like import glib.nim -- I know it is wrong, but compiler error message is not very good (for Linux): Error: cannot open 'glib2/nim' |
| 20:16:10 | Stefan_Salewski | Araq: I know, just for testing. Bye... |
| 20:16:17 | Araq | why? the error message is fine |
| 20:16:26 | Araq | shows the compiler treats the dot as slash |
| 20:17:14 | Stefan_Salewski | Yes, no problem for me. But for beginners? |
| 20:17:41 | Araq | beginners can be smart too |
| 20:18:28 | * | brson quit (Quit: leaving) |
| 20:18:43 | Stefan_Salewski | Bye... |
| 20:18:47 | * | Stefan_Salewski quit () |
| 20:34:13 | * | gokr quit (Quit: Leaving.) |
| 20:39:11 | dts|pokeball | does nimrod have like a pop_front() method for strings? |
| 20:40:31 | Mat4 | hello dts|pokeball |
| 20:40:38 | dts|pokeball | hi Mat4 |
| 20:41:12 | Araq | dts|pokeball: just use slicing |
| 20:41:28 | dts|pokeball | ok |
| 20:42:13 | * | pafmaf joined #nimrod |
| 20:45:50 | Mat4 | dts|pokeball: I've abandoned the port because of the buggy code base for which rewriting from scratch would be easier in my opinion. Anyhow my current IL stuff is uploaded so if you wish to contribute feel free to do so |
| 20:47:27 | dts|pokeball | ok. so just to be clear, youre writing the nim to binary compiler from scratch? |
| 20:49:21 | Joe_knock | dom96: Ready to start? |
| 20:50:16 | dom96 | Joe_knock: I'll be ready in about 10 minutes if that's ok? Just started eating heh. |
| 20:50:34 | Joe_knock | no problem. take your time. We can start at 11ish |
| 20:51:13 | dts|pokeball | splicing returns a string doesnt it? |
| 20:51:43 | Mat4 | dta|pokeball: I plan to port a monitor program for the IL environment which I've coded some years ago and will patch Nim's C generator to emit assembly |
| 20:51:53 | dts|pokeball | ooo cool |
| 20:58:19 | * | uran joined #nimrod |
| 20:59:05 | * | BitPuffin joined #nimrod |
| 21:00:22 | dom96 | Joe_knock: ok, i'm ready. How do you want to do this? |
| 21:03:32 | Joe_knock | I'm glad you asked. I now present: http://collabedit.com/4y9kt tadaa!! |
| 21:04:01 | dom96 | cool |
| 21:04:03 | Joe_knock | We can chat there, or privately here. |
| 21:04:19 | wan | what are you trying to build in real-time collaboration? |
| 21:05:16 | Joe_knock | wan: You're welcome to join us, we're building a todo app to add to Jester examples |
| 21:05:32 | Araq | hi uran welcome |
| 21:07:32 | wan | Joe_knock: ah, alright. Kind of a todomvc back-end, then? I might hop by at some point to see how it's going. |
| 21:08:21 | uran | Hi Araq, thank you |
| 21:08:24 | Joe_knock | wan: That is actually a good point you're mentioning. I wanted to actually submit one here: http://www.todobackend.com/index.html |
| 21:09:23 | * | drewsrem quit (Quit: Leaving) |
| 21:14:26 | * | brson joined #nimrod |
| 21:27:14 | * | milosn quit (Ping timeout: 256 seconds) |
| 21:27:16 | * | uran quit (Ping timeout: 246 seconds) |
| 21:29:17 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 21:33:21 | * | Stefan_Salewski joined #nimrod |
| 21:33:34 | dts|pokeball | how would i cast "r" to a char? |
| 21:35:24 | Araq | char(r) or cast[char](r) |
| 21:35:37 | Araq | the former is preferred |
| 21:35:52 | Stefan_Salewski | Back: Seems that complete import paths does not work at all on linux, with Nim devel compiled a few wekks ago |
| 21:36:48 | Stefan_Salewski | import "/home/stefan/nim-glib/src/glib2" is currently not working for me, while import ../../aaa-bbb/glib2 is fine! |
| 21:36:50 | dts|pokeball | Araq, ah... that makes more sense. i thought i had read chr |
| 21:37:16 | ldlework | Stefan_Salewski: I imagine importing works based off the nim path |
| 21:37:32 | ldlework | Stefan_Salewski: so just add /home/stefan/nim-glib/src to your nim path |
| 21:38:07 | Araq | Stefan_Salewski: maybe, but there have been no changes to the path handling |
| 21:38:24 | Araq | so if it doesn't work, it should never have worked ... |
| 21:38:47 | dts|pokeball | http://paste.ubuntu.com/9387615/ why would i be missing a )? i cant see unbalanced parens anywhere in hte code? |
| 21:39:31 | Stefan_Salewski | Yes, I think I used only something like ../dir/module in the past. |
| 21:39:39 | * | flaviu joined #nimrod |
| 21:39:47 | ldlework | dts|pokeball: is "source: var string" |
| 21:39:50 | ldlework | its* |
| 21:39:55 | dts|pokeball | oh |
| 21:39:56 | dts|pokeball | hmm |
| 21:40:01 | dts|pokeball | i misread the tutorial |
| 21:40:20 | ldlework | Stefan_Salewski: don't embed any information about your environment into how things are imported |
| 21:40:30 | Stefan_Salewski | But I think we should decide how import path may look, and state that in the manual. No problem for me now, thanks. |
| 21:40:31 | ldlework | Stefan_Salewski: put things on the path, and pick the most natural import designation |
| 21:40:36 | ldlework | Stefan_Salewski: like "import glib2" |
| 21:40:58 | ldlework | Stefan_Salewski: certainly we wouldn't want to encourage absolute paths by supporting them |
| 21:41:08 | ldlework | if it doesn't work currently, I'd call it a feature |
| 21:41:56 | Araq | yup |
| 21:42:05 | Araq | it's good that it doesn't work ;-) |
| 21:42:13 | Stefan_Salewski | Idlework: so please at it to the manual... |
| 21:42:35 | * | skyfex quit (Quit: (null)) |
| 21:43:21 | ldlework | Stefan_Salewski: why? |
| 21:43:32 | ldlework | What indicated to you that you -could- or even -should- use absolute paths? |
| 21:43:59 | ldlework | Stefan_Salewski: btw, pull requests are accepted |
| 21:44:31 | Stefan_Salewski | I am sure that people will complain when absolute import paths will not work, at least some German ones. |
| 21:44:37 | ldlework | o_o |
| 21:44:46 | ldlework | Why the hell would being German have anything to do with anything |
| 21:45:13 | flaviu | ldlework: Araq is German, maybe there's a secret German Nim community? |
| 21:45:23 | ldlework | the only appropriate answer here is "Because Germans are the absolute race" |
| 21:45:26 | Stefan_Salewski | And when you ask why put it to manual: Because it is not expected. I t may be OK. |
| 21:45:52 | ldlework | Stefan_Salewski: go ahead, I'm sure Araq would merge your clarification |
| 21:48:39 | Mat4 | Stefan_Salewski: I hope you know this is a public viewable channel |
| 21:49:27 | * | AMorpork is now known as AFKMorpork |
| 21:50:15 | Stefan_Salewski | Sure, I am German, I know some of us like to complain. But I have to do some work still. Bye... |
| 21:50:24 | * | Stefan_Salewski quit () |
| 21:50:29 | ldlework | that was odd |
| 21:53:02 | Mat4 | <8->= |
| 21:53:09 | Mat4 | *lol* |
| 22:02:55 | * | Mat4 tests emoticons |
| 22:04:17 | Araq | these are IRC client dependent |
| 22:05:09 | ldlework | man, right around 2PM I just turn the fuck off |
| 22:05:17 | ldlework | oops |
| 22:07:04 | Mat4 | is this some kind of slang ? |
| 22:07:56 | * | milosn joined #nimrod |
| 22:08:46 | dom96 | If you guys wanna see us coding the todo app join 178.62.143.63 using gobby. |
| 22:09:04 | * | pafmaf quit (Quit: Verlassend) |
| 22:10:07 | Joe_knock | gobby 0.5 |
| 22:10:27 | * | untitaker quit (Ping timeout: 250 seconds) |
| 22:11:42 | Mat4 | ciao |
| 22:11:48 | * | Mat4 left #nimrod (#nimrod) |
| 22:17:48 | * | untitaker joined #nimrod |
| 22:19:28 | * | perturbation joined #nimrod |
| 22:20:20 | * | gour quit (Quit: Konversation terminated!) |
| 22:31:40 | * | rpag_ joined #nimrod |
| 22:32:00 | * | EXetoC quit (Quit: WeeChat 1.0.1) |
| 22:33:12 | * | rpag quit (Ping timeout: 245 seconds) |
| 22:33:22 | * | Stefan_Salewski joined #nimrod |
| 22:34:18 | Stefan_Salewski | Ok, just to correct myself: #import ../../nimgobj/gli2 works fine, but |
| 22:35:38 | Stefan_Salewski | import ../glib2 gives: Error: invalid module name: '../ glib2' |
| 22:37:13 | Stefan_Salewski | So the compiler inserts a space infront of the 'glib2'. Maybe a feature? No problem when we know it. |
| 22:39:11 | Araq | hrm that is strange indeed |
| 22:40:04 | * | AFKMorpork is now known as AMorpork |
| 22:40:54 | Joe_knock | I've never seen anybody want to statically link to something before. |
| 22:41:09 | Joe_knock | Stefan_Salewski: No nimble? |
| 22:41:10 | flaviu | Stefan_Salewski: heh, I just ran across that problem myself right now |
| 22:42:01 | * | gokr_ joined #nimrod |
| 22:42:25 | dts|pokeball | is it just coincedence that nimrod resembles pascal? |
| 22:42:48 | dts|pokeball | like i copied some pascal code,, and most of it is somewhat valid nim |
| 22:43:27 | ldlework | dts|pokeball: Nim is bootstrapped with Pascal code automatically converted to Nim |
| 22:43:38 | dts|pokeball | that makes sense |
| 22:44:03 | dts|pokeball | one of these days ill look through the nim compiler |
| 22:47:26 | * | EXetoC joined #nimrod |
| 22:55:10 | Araq | well Pascal -> Nim is rather easy to do. Nim -> Pascal doesn't work that well: let x = if b: 1 else 0 |
| 22:55:31 | Araq | let x = if b: 1 else: 0 |
| 23:02:35 | flaviu | ldlework: Huh? Nim was originally written in pascal, but now it's bootstraped from C sources. |
| 23:03:04 | ldlework | flaviu: I've read that there was some pascal that was automatically converted to Nim that provided the means for the first strapping |
| 23:03:13 | ldlework | Araq probably knows. |
| 23:03:18 | flaviu | yes, you're right |
| 23:03:25 | ldlework | .. |
| 23:03:49 | flaviu | but from what I can tell, just the first one. Nim hasn't been near pascal for some years AFAIK |
| 23:05:04 | Stefan_Salewski | In Oberon we had * for read/write export, and - to mark identifiers for read-only export: Is read-only export available for Nim too? |
| 23:05:30 | ldlework | flaviu: sure |
| 23:09:46 | * | saml quit (Quit: Leaving) |
| 23:09:57 | Araq | once bootstrapping worked reliably enough I never wrote anything in Pascal anymore |
| 23:10:35 | * | gokr joined #nimrod |
| 23:10:45 | Araq | after a few hundred thousand lines of pascal you learn to loathe the syntax |
| 23:11:21 | Araq | Stefan_Salewski: no but '-' has been discussed and maybe will make it into the language one day |
| 23:12:13 | Stefan_Salewski | Ah thanks. Bye... |
| 23:12:16 | * | Stefan_Salewski quit () |
| 23:13:40 | * | gokr1 joined #nimrod |
| 23:14:08 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 23:24:11 | flaviu | 'Oberon is unusable for any real programming and Wirth confuses simplicity with "the compiler can be implemented by students"', yet it still is interesting enough that you're considering stealing syntax :P |
| 23:26:57 | Araq | no, I stole syntax from it 8 years ago |
| 23:27:27 | Araq | it's only interesting when you ignore time |
| 23:28:41 | * | Stefan_Salewski joined #nimrod |
| 23:29:53 | Stefan_Salewski | Yes. Oberon is a simple language, and there has not been real progress in the last 20 years. |
| 23:30:02 | dts|pokeball | crap... i didnt need to cast a string at all :/ |
| 23:30:57 | Stefan_Salewski | But Oberon was and Operating System written in Oberon too -- first on Ceres workstation, later ported to X86. |
| 23:31:04 | Araq | Stefan_Salewski: no progress on Oberon, you mean |
| 23:32:21 | Stefan_Salewski | Sure, no real progress in Oberon... |
| 23:33:06 | Stefan_Salewski | But Wirth ported his OS and language to an FPGA board recently. |
| 23:33:13 | Araq | Oberon is a horrible language |
| 23:33:34 | Araq | it replaces enums with integers, what's the point of static typing then? |
| 23:34:33 | Araq | it has GC, but arrays still can't grow |
| 23:34:39 | Stefan_Salewski | Some people still follow Oberon -- maybe still useful for embbeded secure devices? |
| 23:36:23 | Stefan_Salewski | Araq: But Oberon also banned unsigned ints :-) |
| 23:36:35 | Araq | so did Java |
| 23:37:11 | flaviu | Araq: Technically, java does have unsigned 16 bit integers |
| 23:37:31 | Araq | flaviu: char? |
| 23:37:31 | flaviu | `char` |
| 23:37:33 | flaviu | yep |
| 23:37:40 | Araq | so does Oberon then |
| 23:38:09 | Araq | Oberon is Java in Pascalish syntax |
| 23:38:18 | Araq | more or less |
| 23:39:00 | Araq | the only real difference is that oberon still has value based objects (records) |
| 23:39:11 | Araq | and arrays |
| 23:41:10 | Araq | the mere fact that Wirth uses ALLUPPERCASE for the keywords makes me wonder if he ever heard of this new thing called "syntax highlighting" |
| 23:42:40 | dom96 | Wirth probably still uses a black and white monitor. |
| 23:44:37 | * | Joe_knock left #nimrod ("Leaving") |
| 23:45:09 | * | MightyJoe quit (Ping timeout: 272 seconds) |
| 23:47:11 | * | MightyJoe joined #nimrod |
| 23:48:19 | * | Stefan_Salewski quit () |
| 23:51:57 | flaviu | dom96: His monitor looks modern: http://www.dr-chuck.com/img/2012/2012-02-24-niklaus.jpg |
| 23:55:57 | willwillson | How did you get along coding the TODO app? |
| 23:59:39 | * | Stefan_Salewski joined #nimrod |
