| 00:11:13 | flaviu | Wow, it looks like the json module doesn't have any noticeable bugs |
| 00:13:11 | * | mwbrown joined #nimrod |
| 00:20:39 | flaviu | A little memory problem though, lol |
| 00:22:54 | * | brson quit (Quit: leaving) |
| 00:26:22 | * | Jesin joined #nimrod |
| 00:44:28 | * | Jesin quit (Quit: rebooting) |
| 00:51:58 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:53:48 | * | xenagi joined #nimrod |
| 01:12:50 | * | ics joined #nimrod |
| 01:34:43 | * | q66 quit (Quit: Leaving) |
| 01:39:04 | darkf | so, stupid question: when I install a library package with babel, how do I import one of the modules? e.g. I'm trying to imoprt https://github.com/fowlmouth/horde3d/blob/master/src/h3d.nim with import h3d but cannot open 'h3d' |
| 01:39:47 | flaviu | So you've done `babel install horde3d`? |
| 01:40:19 | * | Jesin joined #nimrod |
| 01:40:52 | darkf | yup |
| 01:41:10 | darkf | nimrod hints that it adds the .babel\pkgs\horde3d-1.0 path too |
| 01:41:36 | flaviu | just a guess, does src.h3d work? |
| 01:41:48 | flaviu | also try horde3d.h3d |
| 01:42:21 | darkf | heh, src.h3d works but Error: cannot open 'importc_block' |
| 01:42:35 | darkf | there don't seem to be docs for that lib |
| 01:42:49 | * | Jessin joined #nimrod |
| 01:43:47 | adoniscik | it's in https://github.com/fowlmouth/nimlibs |
| 01:44:55 | flaviu | Yep, also make an issue on fowl's horde3d repo. That's a bug, he needs to add a dependency or something. |
| 01:46:04 | flaviu | Actually, it looks like that's a dead import |
| 01:46:12 | flaviu | just delete it |
| 01:46:44 | * | Jesin quit (Ping timeout: 260 seconds) |
| 01:46:54 | darkf | huh, so it is, heh |
| 01:46:57 | darkf | thanks a lot |
| 01:46:58 | * | Jessin is now known as Jesin |
| 01:47:37 | darkf | (well, it might just be that the macro defined there automatically applies to the procs without needing to be called) |
| 01:48:21 | flaviu | It needs to be called to be run, Nimrod doesn't support custom compiler passes or similar. |
| 01:49:15 | darkf | ah, okay |
| 01:57:50 | darkf | hrm, the dynlib pragma works on Windows, right? if I try to run it: could not load: libHorde3D.dll evne though it's in the same directory |
| 02:00:04 | flaviu | shared libraries are always ... fun |
| 02:00:05 | flaviu | I think you have to pass something to the compiler, give me a few seconds |
| 02:00:20 | darkf | haha :) |
| 02:02:02 | * | Jesin quit (Quit: Leaving) |
| 02:02:04 | flaviu | try --dynlibOverride:Horde3d --passL:libHorde3D.dll |
| 02:02:13 | flaviu | and also try putting it in the nimcache folder |
| 02:05:00 | darkf | hrm, yeah... I have to use --cpu:i386 to make it work with the x86 .dll; of course this causes: |
| 02:05:01 | darkf | c:\Program Files (x86)\Nimrod\lib/nimbase.h:382:13: error: size of array 'assert_numbits' is negative typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1]; |
| 02:05:19 | flaviu | Are you using 32 bit gcc? |
| 02:05:29 | flaviu | or whatever your favorite compiler is? |
| 02:05:35 | fowl | darkf, i will make you a collaborator so you can push updates, what is your github username |
| 02:05:49 | darkf | fowl: darkf |
| 02:06:20 | darkf | flaviu: I'm not sure if gcc itself is 64-bit; I believe it does output 64-bit programs without -m32 |
| 02:06:42 | fowl | darkf, cool, thank you :) |
| 02:07:04 | darkf | (I'm also not sure if it's using my gcc or Nimrod's distributed versio) |
| 02:07:12 | darkf | fowl: thanks |
| 02:07:29 | flaviu | darkf: try --passC:-m32 |
| 02:08:10 | flaviu | docs are at http://nimrod-lang.org/nimrodc.html if you haven't found them. They aren't very accessible |
| 02:10:23 | darkf | hrm: c:/program files (x86)/nimrod/dist/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386 architecture of input file `c:\users\bak\desktop\nim\nimcache\blah.o' is incompatible with i386:x86-64 output |
| 02:10:27 | darkf | that's with --cpu:i386 |
| 02:10:33 | mwbrown | Has anyone here had any luck running Nimrod on an embedded system? I'm thinking of doing it on an ARM Cortex M3 |
| 02:11:00 | mwbrown | also, apparently the 16-bit "AVR" cpu type doesn't work. Gives some complaint in system.nim about type matching last time I checked |
| 02:11:16 | flaviu | mwbrown: I've run it on MIPS qemu, and at one point raspberry pi was used as a testing platform |
| 02:11:35 | flaviu | ARM should work great |
| 02:12:05 | mwbrown | I was thinking of getting some quick and dirty setup that just boots the chip and jumps into the Nimrod main function |
| 02:12:14 | mwbrown | or whatever its equivalent is when you compile a nimrod program |
| 02:12:26 | mwbrown | any docs on calling nimrod from C? |
| 02:12:44 | flaviu | mwbrown: its easy, just use the C sources |
| 02:13:17 | flaviu | Not much to it, nimrod is C as far as interop is concerned |
| 02:13:32 | mwbrown | what about function naming? Does nimrod mangle names at all? |
| 02:13:38 | flaviu | I think you have to gc_ref/gc_unref sometimes, but that shouldn't matter |
| 02:13:56 | flaviu | mwbrown: Yeah, it does, but there's an exportc pragma |
| 02:14:03 | mwbrown | ah |
| 02:48:07 | * | Boscop quit (Read error: Connection reset by peer) |
| 02:48:57 | * | Boscop joined #nimrod |
| 03:05:06 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 03:33:13 | * | MayurYa quit (Quit: *nix server crashed w/ bof) |
| 03:53:13 | mwbrown | flaviu: you still active? |
| 03:53:27 | flaviu | yep, going to bed soon though |
| 03:53:30 | mwbrown | alright |
| 03:53:32 | mwbrown | quick question though |
| 03:53:36 | flaviu | Not for ~20 min though |
| 03:53:42 | flaviu | sure, what question? |
| 03:53:53 | mwbrown | do you know what the --cpu:SYMBOL thing affects when you set to say ARM vs i386? |
| 03:54:09 | mwbrown | obviously the biggest difference is what GCC you use to compile it with, since Nimrod only goes to C |
| 03:54:22 | flaviu | I think it also changes the int size |
| 03:54:39 | mwbrown | because there's a big difference between an ARM Cortex A8 vs. a Cortex M3 |
| 03:54:47 | mwbrown | but when it comes to data types, they're the same size and endianness |
| 03:55:35 | mwbrown | I think I might be able to get this program to work as a single nim file if I compile it right. libopencm3 already provides startup files and interrupt vectors built into the lib |
| 03:55:57 | mwbrown | i.e. no assembly or helper C file required |
| 03:56:31 | flaviu | Have you tried running it on the chip? |
| 03:56:50 | mwbrown | haven't gotten it fully compiled yet. I need to link it with opencm3 with the right linker script for that to work |
| 03:56:56 | flaviu | I don't really understand what you're trying to do |
| 03:57:10 | mwbrown | Just trying to get it to compile and run on a small ARM Cortex M3 |
| 03:57:14 | mwbrown | something like an STM32F3 |
| 03:57:25 | mwbrown | 48k of RAM ;) |
| 04:00:16 | flaviu | mwbrown: https://github.com/Araq/Nimrod/blob/devel/compiler/platform.nim tells you what the --cpu:SYMBOL does |
| 04:01:15 | mwbrown | ah, ok. It just sets up the basics for compile-time asserts it looks like |
| 04:03:08 | * | ics joined #nimrod |
| 04:04:24 | * | xenagi quit (Quit: Leaving) |
| 04:09:27 | * | saml_ quit (Ping timeout: 245 seconds) |
| 04:11:43 | mwbrown | Now I just have to find a way to get it to not pass in -ldl to the linker. Either that or just pass --noLinking and handle the link step myself |
| 04:11:47 | mwbrown | honestly that might just be simpler |
| 04:58:24 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 04:59:26 | * | Matthias247 joined #nimrod |
| 05:07:10 | * | superfunc joined #nimrod |
| 05:08:06 | * | Demos quit (Quit: Leaving) |
| 05:16:05 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 05:16:28 | * | flaviu quit (Ping timeout: 255 seconds) |
| 05:43:20 | * | MayurYa joined #nimrod |
| 05:43:28 | * | MayurYa quit (Changing host) |
| 05:43:28 | * | MayurYa joined #nimrod |
| 05:54:35 | * | mwbrown quit (Ping timeout: 255 seconds) |
| 06:00:33 | * | CARAM_ quit (Read error: Connection reset by peer) |
| 06:05:48 | * | CARAM_ joined #nimrod |
| 06:06:58 | adoniscik | is it possible to disable specific warnings in specific files? |
| 06:09:00 | adoniscik | yep, with {.warning.}. man I love this language |
| 06:12:17 | * | superfunc quit (Ping timeout: 245 seconds) |
| 06:18:41 | * | ics joined #nimrod |
| 06:26:02 | * | CARAM_ quit (Ping timeout: 272 seconds) |
| 06:31:17 | * | CARAM_ joined #nimrod |
| 06:36:08 | * | fowl quit (Ping timeout: 250 seconds) |
| 06:37:55 | * | fowl joined #nimrod |
| 06:42:21 | * | kunev joined #nimrod |
| 06:56:20 | * | darkf quit (Ping timeout: 240 seconds) |
| 06:57:25 | * | darkf joined #nimrod |
| 07:01:49 | adoniscik | argh, I just had a rude introduction to matrix ordering. I'm writing a wrapper to a Fortran library so I have to convert between row and column major ordering |
| 07:01:54 | adoniscik | this can't be good for performance |
| 07:15:00 | * | darkf_ joined #nimrod |
| 07:15:32 | * | darkf quit (Ping timeout: 240 seconds) |
| 07:22:43 | * | kunev quit (Quit: leaving) |
| 07:28:01 | * | kunev joined #nimrod |
| 07:33:23 | Araq | adoniscik: you never know, it can be completely in the noise |
| 07:33:31 | Araq | or it can make a real difference |
| 07:34:12 | Araq | my guess is "noise" ;-) |
| 07:34:20 | Araq | modern cpus are very strange |
| 07:34:39 | adoniscik | what do you mean, that it doesn't affect performance? |
| 07:36:14 | adoniscik | another peculiarity of Fortran is all variables are passed by reference, so my wrapper is littered with ptrs. I wish I could use a pragma and apply it to all variables |
| 07:38:15 | Araq | yeah, like .byRef |
| 07:38:41 | Araq | in fact, all arrays are passed by pointers already |
| 07:39:13 | Araq | I mean the *copies* at the language boundaries could be free |
| 07:39:32 | Araq | not the memory layout doesn't matter for computing, it certainly does |
| 07:40:29 | Araq | "The ``byref`` pragma can be applied to an object or tuple type and instructs |
| 07:40:30 | Araq | the compiler to pass the type by reference (hidden pointer) to procs." |
| 07:40:32 | Araq | bbl |
| 07:40:48 | adoniscik | yeah, I noticed that bit. great thing about byref, I'm trying it now |
| 07:41:06 | * | darkf_ is now known as darkf |
| 07:42:14 | adoniscik | I meant that bit about arrays by pointers |
| 07:44:13 | adoniscik | just to be clear, defining T as {.byref.} means I can eliminate an addr/ptr pair? |
| 07:45:12 | adoniscik | where T is the type of the arg that needs to be passed by pointer |
| 07:46:20 | adoniscik | foo(x : T) instead of foo(addr x) |
| 08:09:17 | * | superfunc joined #nimrod |
| 08:13:44 | * | superfunc quit (Ping timeout: 250 seconds) |
| 08:19:50 | adoniscik | g'night ,folks. byref seems not to work with aliased typedefs; e.g., type foo {.byref.} = bar |
| 08:20:26 | adoniscik | talk about it tomorrow... |
| 08:24:53 | * | adoniscik quit (Ping timeout: 240 seconds) |
| 08:41:16 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:48:29 | * | io2 joined #nimrod |
| 09:03:33 | * | Matthias247 joined #nimrod |
| 09:51:36 | * | zahary quit (Ping timeout: 260 seconds) |
| 10:09:27 | * | superfunc joined #nimrod |
| 10:13:37 | * | superfunc quit (Ping timeout: 245 seconds) |
| 11:09:38 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 11:28:54 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 12:21:28 | * | saml_ joined #nimrod |
| 12:35:23 | * | untitaker quit (Ping timeout: 264 seconds) |
| 12:39:01 | * | mwbrown joined #nimrod |
| 12:40:13 | * | untitaker joined #nimrod |
| 12:41:05 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 12:52:29 | * | darkf quit (Quit: Leaving) |
| 12:59:40 | * | flaviu joined #nimrod |
| 13:08:11 | Skrylar | Araq: i broke your typechecker :( https://github.com/Araq/Nimrod/issues/1424 |
| 13:14:37 | * | saml_ quit (Quit: Leaving) |
| 13:24:20 | * | mwbrown quit (Ping timeout: 250 seconds) |
| 13:32:49 | flaviu | Skrylar: I don't that's a bug. openarrays are defined as a [vals: pointer, len: int], and an array can't be anything but a [vals: pointer]. Cast overrides all the sanity checks. |
| 13:43:53 | * | Trustable joined #nimrod |
| 14:10:30 | * | Boscop_ joined #nimrod |
| 14:11:03 | * | superfunc joined #nimrod |
| 14:13:52 | * | Boscop quit (Ping timeout: 260 seconds) |
| 14:15:34 | * | superfunc quit (Ping timeout: 264 seconds) |
| 14:16:03 | * | Boscop_ quit (Read error: Connection reset by peer) |
| 14:16:29 | * | Boscop_ joined #nimrod |
| 14:48:16 | * | ics joined #nimrod |
| 15:07:47 | * | kunev quit (Quit: leaving) |
| 15:17:13 | * | Demos joined #nimrod |
| 15:33:57 | * | Trustable1 joined #nimrod |
| 15:35:02 | * | Trustable quit (Ping timeout: 240 seconds) |
| 16:05:07 | * | flaviu quit (Read error: Connection reset by peer) |
| 16:07:51 | * | flaviu joined #nimrod |
| 16:12:15 | * | superfunc joined #nimrod |
| 16:14:25 | * | linkmonitor joined #nimrod |
| 16:15:57 | * | othello joined #nimrod |
| 16:16:46 | * | superfunc quit (Ping timeout: 264 seconds) |
| 16:31:04 | othello | hello, sorry to ask a newb question, but I'd like to know how to get the underlying type of sequence? |
| 16:31:16 | othello | *a sequence, sorry |
| 16:32:10 | othello | e.g. I have a tuple TMyTuple[a: int, b: seq[string], c: string] |
| 16:33:06 | othello | if I have var test: TMyTuple, and all I can access is test[1] or test.b |
| 16:33:27 | othello | is it possible to retrieve the type string from test[1] or test.b? |
| 16:35:49 | Demos | does type(test[1]).name work |
| 16:35:58 | Demos | I think you need the typetraits module for the name function |
| 16:44:04 | othello | thanks, it works! But then is there a way to build a var using that type represented as string? |
| 16:46:11 | Demos | as the var name? |
| 16:46:23 | * | io2 joined #nimrod |
| 16:53:40 | * | brson joined #nimrod |
| 16:55:11 | * | Matthias247 joined #nimrod |
| 17:01:54 | othello | Demos: no using it as the type in a newSeq[T] construct |
| 17:02:17 | othello | except of course, there is a more straightforward way of building the sequence in the first place |
| 17:02:26 | Demos | why not just do newSeq[type(test[1])]? |
| 17:02:46 | othello | because then I get a seq[seq[string]] |
| 17:03:03 | Demos | well that should not happen |
| 17:03:25 | Demos | oh, erm well yeah |
| 17:03:42 | Demos | test[1] is of type seq[string] |
| 17:03:46 | Demos | what type did you want? |
| 17:03:59 | Demos | oh a string |
| 17:04:17 | othello | exactly |
| 17:04:21 | Demos | try type(test[1][1]) |
| 17:04:32 | Demos | I am not sure if the thing in the type is evaluaged, probably not |
| 17:04:43 | othello | it worked! |
| 17:04:46 | othello | strange |
| 17:04:56 | Demos | not really.... this is desired behavior |
| 17:05:18 | Demos | you could probably say type(test[1][100000]) as well |
| 17:05:29 | * | q66 joined #nimrod |
| 17:05:41 | othello | yes, but it even worked on an uninitialized variable |
| 17:06:00 | othello | i.d. var test: TMyTuple |
| 17:06:23 | othello | var builtSeq = newSeq[type(test[1][1])]() |
| 17:06:40 | * | adoniscik joined #nimrod |
| 17:06:40 | Demos | yeah |
| 17:06:50 | Demos | again the thing in type() is not evaluated |
| 17:06:54 | othello | ah ok, it's because it's just a type check |
| 17:06:58 | othello | got it |
| 17:07:36 | othello | the type proc is evaluated at compile time anyway, right? |
| 17:08:05 | Demos | well type is a magic |
| 17:08:08 | Demos | but yeah |
| 17:08:37 | Demos | there is no way to get the type at runtime unless you store type information someplace (objects that inheret from stuff do this) |
| 17:09:08 | Demos | be thankfull type((test[1][1])) is the same as type(test[1][1]) |
| 17:09:40 | othello | thanks so much for your help & clarifications |
| 17:09:45 | othello | sorry for the bother |
| 17:11:03 | Demos | no bother at all! if we did not want to help out we would not be in this channel |
| 17:19:23 | * | bjz_ joined #nimrod |
| 17:22:17 | * | bjz quit (Ping timeout: 245 seconds) |
| 17:29:01 | Demos | how much interest is there in a Direct3D 11 wrapper? |
| 17:32:29 | Araq | sounds very good, but an update for the zeromq wrapper is more important |
| 17:32:52 | Araq | sux that we still have outdated wrappers in the stdlib |
| 17:33:39 | Araq | sux even more that people don't know about API design and so need to change everything constantly |
| 17:34:12 | NimBot | Araq/Nimrod devel d9b5ae1 def [+0 ±3 -0]: Allow arguments for "nimrod run" |
| 17:34:12 | NimBot | Araq/Nimrod devel 1274953 def [+0 ±1 -0]: normalize "run" command |
| 17:34:12 | NimBot | Araq/Nimrod devel 4eccfb9 Andreas Rumpf [+0 ±3 -0]: Merge pull request #1422 from def-/nimrod-run2... 2 more lines |
| 17:35:46 | dom96 | hi |
| 17:37:42 | Demos | Does anyone really know about API design, it seems to be a thing that is aquired by experience and wisdom |
| 17:37:51 | Demos | I have a d3d wrapper sitting on github I think |
| 17:38:11 | Demos | or rather bitbucket |
| 17:39:23 | NimBot | Araq/Nimrod devel 2577c92 Joshua Cearley [+0 ±1 -0]: Add better support for unsigned ints via typeinfo. |
| 17:39:23 | NimBot | Araq/Nimrod devel 651f512 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1408 from Skrylar/skry-unsigned-any... 2 more lines |
| 17:39:58 | Demos | it could use some nimrodic sugra |
| 17:40:24 | Araq | Demos: no, it's *very* simple |
| 17:40:40 | Araq | but you're right that nobody knows it |
| 17:40:45 | Araq | I should blog about it, I guess |
| 17:40:45 | Demos | result = device.lpvtbl.CreateRenderTargetView(device, cast[ptr ID3D11Resource](pBackBuffer), addr rtvdesc, addr rtv) is not exactly ideal |
| 17:40:55 | Demos | yes! |
| 17:41:02 | Demos | and recomend some books |
| 17:41:19 | Araq | books are often written by people who have time to write books |
| 17:41:29 | Araq | that's a major problem ;-) |
| 17:42:06 | Demos | yes which is why you should recomend them.... API design is also somewhat of an abstract topic and I wager a lot of the books are full of hot air |
| 17:43:20 | Demos | the whole OOP "coupling and cohesion" thing where they never talk about how those two things are often mutually exclusive |
| 17:43:37 | Demos | well OOP APIs in general tick me off |
| 17:44:49 | Araq | your device stuff looks like it needs some overloaded '.' |
| 17:45:43 | Araq | macros are an alternative but then you're stuck with %foo(bar, baz) or wrap that again so that it becomes foo(bar, baz) |
| 17:46:05 | Araq | which is really not feasible for hundreds of procs |
| 17:46:19 | Araq | well perhaps it is via codegen |
| 17:46:32 | Demos | yeah, I make a point to keep the wrapper as close to the C version as I can, that sugar will be in another module |
| 17:48:23 | Araq | btw IMHO this shows how foolish this whole COM thing really is |
| 17:48:58 | Araq | why the indirection of a vtable? DLLs already provide the perhaps required indirection |
| 17:50:29 | Araq | do they really have multiple different implementations that they pick after DLL loading? and if so, why? |
| 17:58:51 | * | superfunc joined #nimrod |
| 17:59:19 | Demos | well I think they use it for versioning, so I can use a ID3D11Something2 with the ID3D11Device |
| 17:59:49 | Demos | but getting the newer versions of stuff often requires doing a QueryInterface on the old version, which is dumb |
| 18:00:03 | Demos | COM as a whole is pretty dumb |
| 18:00:28 | Demos | and OpenGL has the same thing, the DLL only has the functions to get the function pointers... |
| 18:00:47 | Demos | but yeah, COM is a total clusterfuck |
| 18:01:11 | adoniscik | whadaya expect, coming from MS :) |
| 18:01:35 | Demos | I remember a post on like gamedev.net where someone was like "I am reading this book about how great COM and ATL is and I want to make my whole game like that!" the first reply was "put the book down, now slowly walk away and contimplate your life" |
| 18:06:07 | * | Trustable1 quit (Remote host closed the connection) |
| 18:25:11 | * | gsingh93 joined #nimrod |
| 18:26:01 | NimBot | Araq/Nimrod devel 06bbd6e def [+0 ±1 -0]: flush -> flushFile in doc |
| 18:26:01 | NimBot | Araq/Nimrod devel 13875e5 Simon Hafner [+0 ±1 -0]: Merge pull request #1425 from def-/flush-doc... 2 more lines |
| 18:27:52 | Matthias247 | Demos: it might me. But otherwise it's one of the cores of a pretty much used OS and has been around for ages. So it can't be too bad ;) |
| 18:28:11 | Demos | have you used it? it is pretty bad |
| 18:28:32 | Matthias247 | I've used it for DirectX - a llong long time ago |
| 18:28:52 | Demos | the very strong versioning it has means microsoft can really change their APIs at a fast pace, and this has paid off for Direct3D, but otherwise it is just bad |
| 18:28:54 | Matthias247 | but at least I have better memories about that than about OpenGL :) |
| 18:28:58 | Demos | and direct3D is "COM lite" |
| 18:30:14 | Demos | modern OpenGL is OK, actually with the explicit layout, binding points, and locations, as well with the seperate layout extension it is almost exactly the same model as Direct3D11 |
| 18:31:36 | Matthias247 | but I read Microsoft now also provides "hat pointers" for easy COM ;) |
| 18:32:03 | Demos | yeah they have a whole fucking extension to C++ |
| 18:33:10 | Demos | they also have like 4 smart pointer classes that all work in different ways |
| 18:33:47 | * | Trustable joined #nimrod |
| 18:33:53 | Matthias247 | hmm, c++ standard has also 4 |
| 18:34:02 | Matthias247 | and boost and QT provide even more ;) |
| 18:34:32 | Demos | well all 4 of microsoft's are supposed to work like shared_ptr |
| 18:35:08 | Matthias247 | I really would like ^ hat or sth. else for shared_ptr |
| 18:35:13 | Matthias247 | hate the verboseness |
| 18:35:24 | Demos | but some of them increment the ref count when you attach an object, some do not, some allow conversions with &, actually I think two of them allow & and use it differently |
| 18:35:25 | Matthias247 | and rust even followed that :) |
| 18:35:36 | Demos | meh |
| 18:35:58 | Demos | more kinds of pointers (or any kind of type qualifier) is a bad thing |
| 18:36:47 | Demos | and the whole CoCreateInstance and GUID thing, DCOM and a TOTAL shitshow, the fact that COM always seems more verbose than the much simpler POSIX API |
| 18:37:01 | Demos | heck seems more verbose than the windows API sometimes |
| 18:37:36 | * | mwbrown joined #nimrod |
| 18:37:55 | Matthias247 | but you can use from VB :-) |
| 18:38:07 | mwbrown | flaviu: I got Nimrod running on that small ARM chip yesterday |
| 18:38:20 | mwbrown | I was able to set up a two-second timer interrupt and hit breakpoints on it, so nothing interesting yet |
| 18:41:39 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:42:40 | linkmonitor | Interesting. Mind if I ask which flavor of ARM chip? We talking M0? |
| 18:42:49 | mwbrown | linkmonitor: STM32F303 |
| 18:42:55 | mwbrown | 48k of RAM |
| 18:43:05 | mwbrown | technically 40K + 8K core-coupled |
| 18:43:19 | mwbrown | the linker script separates them out, so I don't know if the 8K is directly accessible without some magic involved |
| 18:43:45 | mwbrown | linkmonitor: it's also an M4 chip, which if I remember right is just the M3 plus some DSP instructions |
| 18:45:10 | mwbrown | The only thing I'm worried about so far is what will happen if an interrupt is implemented in Nimrod. I don't want the GC doing anything during an interrupt, but I don't think there is any pragma that lets you temporarily suspend it |
| 18:45:20 | * | Johz joined #nimrod |
| 18:45:38 | Matthias247 | cool |
| 18:45:41 | mwbrown | not to mention it will have to execute in a different context than non-interrupt code, so there could be some weirdness there depending on when the switch occurs |
| 18:45:46 | Matthias247 | you have it running with the GC? |
| 18:46:07 | mwbrown | Matthias247: unless there is something I have to do to explicitly disable it, I assume it's running |
| 18:46:23 | linkmonitor | isn't there GC_disable() in the system module? |
| 18:46:34 | Matthias247 | mwbrown: if you can use ref pointers then it's probably running :) |
| 18:46:51 | mwbrown | Matthias247: haven't tried that yet. The only code I've run so far is the following: |
| 18:46:55 | mwbrown | https://github.com/mwbrown/nimrod_stm32f3 |
| 18:47:12 | mwbrown | specifically https://github.com/mwbrown/nimrod_stm32f3/blob/master/src/main.nim |
| 18:49:43 | linkmonitor | Probably too soon to ask, but any idea how much RAM you're using? |
| 18:50:48 | linkmonitor | Off to lunch, but I'll read the logs to catch back up. |
| 18:51:05 | Matthias247 | according to that code it should use next to 0 ;) |
| 18:52:04 | mwbrown | linkmonitor: It depends on how big the bss section ends up being. There's no heap so it is all statically-allocated |
| 18:52:50 | Matthias247 | but there's a stack :) |
| 18:53:57 | mwbrown | true. No idea how much stack that Nimrod uses compared to bare C |
| 18:55:35 | mwbrown | The stack is just whatever you have left over from the other memory, since it's at the very end. Linker script has this line: |
| 18:55:36 | mwbrown | PROVIDE(_stack = ORIGIN(ram) + LENGTH(ram)); |
| 18:55:47 | Matthias247 | but if there's no heap and no malloc then the question is which memory the GC uses ;) |
| 18:55:56 | mwbrown | although you could stick the stack in the CCM region and then be reasonably assured you have 8K of untouched ram, and leave 40k for everything else |
| 19:00:39 | mwbrown | only thing I'm not looking forward to in this project is converting all those header files. libopencm3 has some magic somewhere IIRC |
| 19:00:45 | * | Jesin joined #nimrod |
| 19:00:54 | mwbrown | they like to redefine symbols to make them CMSIS-compliant |
| 19:01:13 | mwbrown | but in Nimrod I don't get access to that, so my interrupt handler has to be sys_tick_handler instead of the CMSIS symbol SysTick_Handler |
| 19:02:30 | * | Ven joined #nimrod |
| 19:03:04 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 19:03:45 | Matthias247 | what does opencm3 provide over cmsis? |
| 19:04:42 | mwbrown | it's got helper functions and provides easy-to-use vector tables in your project. From what I understand you don't have to hunt down functions from each vendor, for instance, if you want to port your project from a STMicro chip to an Atmel chip |
| 19:05:06 | mwbrown | I could have used the STMicro stdperipheral library, but it's slightly less portable and more involved to set up |
| 19:07:11 | Matthias247 | you can also use autosar and mcal ;) |
| 19:07:25 | Matthias247 | ok, you probably better won't :) |
| 19:07:49 | mwbrown | ha |
| 19:08:01 | mwbrown | looked it up, saw the word "automotive" and noped right out of there |
| 19:09:38 | Matthias247 | an extremly big extremly "standardized" RTOS for automotive microcontrollers. Including an hardware abstraction layer, PDU message router, etc. |
| 19:10:58 | Matthias247 | as a bonus you need extremly expensive tools and lots of XML to build the software :) |
| 19:11:16 | mwbrown | not to mention being trained in writing MISRA-compliant code I imagine |
| 19:11:40 | * | Jesin quit (Quit: Leaving) |
| 19:12:34 | Matthias247 | yes, misra is also in there |
| 19:22:08 | * | io2 joined #nimrod |
| 19:23:47 | * | Jesin joined #nimrod |
| 19:25:37 | * | Jesin quit (Max SendQ exceeded) |
| 19:26:23 | * | Jesin joined #nimrod |
| 19:40:10 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 19:40:20 | flaviu | type pragma? |
| 19:40:41 | flaviu | sorry, that was an old conversation |
| 19:46:21 | Varriount | Meep! |
| 19:48:03 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:00:04 | adoniscik | speaking of type pragmas, does .byref. work with arbitrary types? |
| 20:00:21 | adoniscik | such as type integer* {.byref.} = clong? |
| 20:00:28 | adoniscik | It didn't for me |
| 20:01:10 | Varriount | adoniscik: 'type integer = ref clong'? |
| 20:02:32 | adoniscik | I suppose. What about arrays? When you have array[I, foo] and you want to use foo as a ref outside of the array, do you have to create a separate, alias type? |
| 20:05:00 | Varriount | var x: ref foo = arr[i] should work, I think |
| 20:07:04 | adoniscik | actually ref did not work so well either. When you want to define a new variable type T : ref int, you can't say x : T = 1 because T is a ref, so you need to allocate a new T too, defeating my goal of trying to avoid so many addrs and ptrs. See what I mean? |
| 20:11:59 | * | ics joined #nimrod |
| 20:14:14 | flaviu | adoniscik: I think that'd be unsafe |
| 20:14:39 | Araq | var x: ref foo = arr[i] does not work and shouldn't |
| 20:14:45 | flaviu | taking a refrence of an element in an array would lead to bad pointers should the array go away |
| 20:15:12 | Araq | adoniscik: you're doing it wrong. ;-) |
| 20:15:26 | adoniscik | I merely want args to be passed by reference; I don't want to define the variables themselves as refs |
| 20:15:36 | adoniscik | remember we talked about byref last night? |
| 20:15:43 | adoniscik | I could not get it to work |
| 20:15:58 | Araq | well I already told you arrays don't require .byref and it works for objects |
| 20:16:16 | Araq | unless you have some crazy type aliasing perhaps |
| 20:16:37 | adoniscik | I have C types; cint, clong, etc. |
| 20:16:45 | Araq | and no, it doesn't work for 'int' but then 'var int' kind of does |
| 20:17:17 | Araq | C doesn't pass cint by ref anyway, but hmm you said it's Fortran, right? |
| 20:17:41 | adoniscik | correct, C wrapper to a Fortrant library |
| 20:17:50 | adoniscik | it's complicated, math stuff |
| 20:18:06 | Araq | your best choice is 'var T' then |
| 20:18:18 | Araq | no ideal, but hopefully good enough |
| 20:18:21 | adoniscik | good, that worked |
| 20:18:41 | Araq | make a feature request please |
| 20:18:43 | adoniscik | at least I got rid of all the addrs on the "client" side |
| 20:18:52 | Araq | we care about good old Fortran |
| 20:19:01 | adoniscik | better leave the ugliness to the library side |
| 20:19:08 | adoniscik | which nobody has to see |
| 20:19:47 | Araq | yeah, but importf is not science fiction |
| 20:21:04 | Araq | it's not hard to implement ... (famous last words) |
| 20:21:18 | adoniscik | if I have to pass an array to a Fortran library, do I have to manually transpose it from row-major to column-major form, is there some sugar/helper function/pragma I can apply? |
| 20:22:23 | Araq | there is nothing like that |
| 20:22:36 | Araq | you can however do something like: |
| 20:22:50 | Demos | how much cruft is in typical fortran, I know ye olde fortran had nasty stuff like textual import and a preprocessor |
| 20:23:18 | Araq | type FortranArray[T] {.unchecked.} = distinct array[1, T] |
| 20:23:55 | Araq | converter toFortranArray[I, T](x: array[I, T]): FortranArray[T] |
| 20:24:12 | Araq | with a bit of luck this works with today's compiler ... |
| 20:24:50 | Araq | proc foo(a: FortranArray[float]) {.importc: "foo", ... .} |
| 20:24:53 | adoniscik | yeah, coz I am using incantations like proc foo[A,B,C,D, ...] to feed each array its own range |
| 20:25:15 | adoniscik | it's an alphabet soup :) |
| 20:25:55 | Araq | hmm I can imagine |
| 20:26:06 | Araq | well you can always do it more low level |
| 20:26:22 | Araq | like array[N*M*P, float] |
| 20:27:12 | Araq | and then have some accessors |
| 20:27:21 | Araq | this way you also don't need to transpose anything |
| 20:31:36 | NimBot | Araq/Nimrod devel 779f2b3 Dominik Picheta [+0 ±1 -0]: Fixes typeinfo after PR #1408 broke it. |
| 20:31:57 | * | Jessin joined #nimrod |
| 20:33:01 | Varriount | Hey Araq, where in the documentation should the style guide be mentioned? |
| 20:34:29 | adoniscik | Araq, when you defined FortranArray, did you mean really array[1, T] (number) or array[I, T] (interval)? |
| 20:34:53 | flaviu | adoniscik: array[1, T] |
| 20:34:57 | * | Jesin quit (Ping timeout: 256 seconds) |
| 20:35:02 | adoniscik | okay |
| 20:35:04 | flaviu | The {.unchecked.} pragma turns off bounds checking |
| 20:35:31 | flaviu | I personally prefer array[0..0, T], but it doesn't matter |
| 20:36:40 | Araq | Varriount: well we need some better documentation overview page |
| 20:36:50 | Araq | people already don't find anyting in this "overview" |
| 20:37:06 | Araq | I have no idea how to improve it though... |
| 20:37:50 | flaviu | Search? |
| 20:40:26 | adoniscik | I get an implementation expected error |
| 20:41:37 | flaviu | adoniscik: Can you gist the relevant portions? |
| 20:41:54 | adoniscik | just what we discussed: FArray[T]* {.unchecked.} = distinct array[0..0, T] |
| 20:42:02 | adoniscik | Error: implementation of 'FArray' expected |
| 20:42:10 | adoniscik | this is inside a "type" blcok |
| 20:43:35 | flaviu | type FArray* {.unchecked.} [T] = distinct array[0..0, T] |
| 20:44:07 | adoniscik | oh |
| 20:44:07 | flaviu | its hard to remember the order, just rearrange the *, {. ... .}, and [Ts] |
| 20:44:42 | adoniscik | basically I got it totally wrong :) |
| 20:47:22 | Varriount | Araq: I could ask one of the website reddits to give suggestions... |
| 20:49:23 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:51:27 | adoniscik | The converter Araq wrote does not work with array expressions, whose type is array _constructor_. I could nto find a way to declare array constructors as converter args |
| 20:52:03 | Araq | Varriount: hmm getting useful feedback from the Internet ... that's a new concept for me |
| 20:52:40 | Araq | adoniscik: yeah well ... sorry |
| 20:53:17 | adoniscik | I've run into problems with the difference between arrays and array constructors before, so this is a good opportunity for me to learn I guess :) |
| 20:58:35 | Araq | well no |
| 20:58:40 | Araq | these are just bugs... |
| 20:58:41 | mwbrown | Matthias247: just confirmed that the ARM chip is NOT in fact using the GC and cannot until some other code is present |
| 20:59:08 | mwbrown | Matthias247: tried adding a ref type and called new() on it, got the following error: "system module needs 'nimGCunrefNoCycle'" |
| 21:00:14 | adoniscik | Araq, are you responding to me? So I should not be getting errors like Error: type mismatch: got (Array constructor[0..15, cdouble]) but expected 'FArray[cdouble]'? |
| 21:01:03 | Araq | adoniscik: correct |
| 21:06:53 | * | Jesin joined #nimrod |
| 21:08:33 | * | Jessin quit (Ping timeout: 240 seconds) |
| 21:13:57 | * | Jesin quit (Ping timeout: 245 seconds) |
| 21:16:43 | * | io2 joined #nimrod |
| 21:18:19 | * | Trustable1 joined #nimrod |
| 21:18:27 | * | Trustable1 quit (Remote host closed the connection) |
| 21:20:04 | flaviu | I'd guess and say that Array constructor[I, T] needs to be a subtype of Array[I, T]? |
| 21:21:21 | Araq | subtype, supertype, all banana |
| 21:21:39 | Araq | array constructor needs to be removed from the language |
| 21:21:54 | Araq | what it accomplishes can be easily done with other mechanisms |
| 21:22:07 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 21:22:23 | Araq | as far as I remember it's not part of the spec either |
| 21:22:45 | * | Ven joined #nimrod |
| 21:43:09 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:47:06 | * | Jesin joined #nimrod |
| 21:47:36 | adoniscik | do you have any suggestions in the meantime? |
| 21:48:29 | Araq | do you have a simple test case that triggers it? |
| 21:51:53 | adoniscik | any array? Try let x: FArray[int] = [1,2,3] |
| 21:52:20 | adoniscik | As simple as it gets |
| 21:52:24 | Araq | make a gist please |
| 21:53:38 | adoniscik | http://pastebin.com/E2GDjGce |
| 21:54:32 | Demos | how do people like to deal wtih exceptions, just stick them in the file where they are thrown? common file? a mix? |
| 21:54:48 | Demos | the declerations that is |
| 21:55:07 | Araq | adoniscik: well 'distinct' obviously is not compatible with its underlying base type |
| 21:55:15 | Araq | that's the purpose of the 'distinct' |
| 21:56:07 | * | Jessin joined #nimrod |
| 21:58:01 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:59:22 | * | Jesin quit (Ping timeout: 260 seconds) |
| 22:00:20 | * | Johz quit (Remote host closed the connection) |
| 22:01:21 | * | Jessin quit (Quit: Leaving) |
| 22:02:36 | adoniscik | removing the distinct didn't make a difference though. What am I missing? |
| 22:03:25 | Araq | well the 'unchecked' doesn't mean type checking is disabled |
| 22:03:48 | Araq | so an array of length 5 is not compatible to an array of length 1 |
| 22:05:56 | adoniscik | so what does this "unchecking" achieve if the base types match? |
| 22:07:47 | adoniscik | I feel as though we are where we started |
| 22:07:57 | Araq | that you can at runtime do a[4] when there is officially no such index |
| 22:08:52 | * | Trustable quit (Quit: Leaving) |
| 22:12:22 | flaviu | adoniscik: Maybe a converter from array[I, T] to FArray[T]? |
| 22:12:40 | flaviu | that uses cast, although cast does do memcpy iirc |
| 22:12:53 | adoniscik | I fail to see how that helps. Recall that we were trying to avoid the generic alphabet soup of proc foo[A,B,C,D,...] that arise from the need to declare array intervals |
| 22:13:10 | adoniscik | flaviu, right, but you get the same array constructor error |
| 22:13:21 | adoniscik | or maybe I do since I made a mistake; please try it yourself |
| 22:13:34 | adoniscik | I tried both converter toFArray[I, T] (x: array[I, T]): FArray[T] = FArray(x) and converter toFArray[I, T] (x: array[I, T]): FArray[T] = cast[FArray](x) |
| 22:14:53 | adoniscik | is this converter supposed to be invoked automatically, because it is not (for the same reason: it sees an array _constructor_, not an array)? |
| 22:18:19 | flaviu | Well, I got it to compile, but it segfaults |
| 22:20:26 | flaviu | Oh, I see. Recursive call in the converter |
| 22:22:56 | flaviu | adoniscik: Ok, got it: https://gist.github.com/7aab80daa9e13fcac456 |
| 22:24:11 | flaviu | I stick it in a local var so I can get a pointer to it, and then I take the address, which discards all the type information. That can then be casted |
| 22:24:49 | adoniscik | I would not have thought of that. |
| 22:24:57 | adoniscik | and indeed I did not :) |
| 22:25:29 | flaviu | It does involve a memcpy though |
| 22:26:24 | adoniscik | okay so if we're in the business of copying, this looks like just the right place to do the row-major order to column-major order conversion |
| 22:28:27 | adoniscik | actually it did not work for me, so something must have got fixed since 0.94 |
| 22:28:33 | OrionPK | hello all |
| 22:29:42 | * | superfunc quit (Ping timeout: 260 seconds) |
| 22:29:45 | flaviu | Actually, that code may be broken. It seems I'm hitting undefined behavior |
| 22:30:09 | adoniscik | but you don't get the type mismatch error I do |
| 22:33:15 | flaviu | adoniscik: What error do you get |
| 22:33:26 | adoniscik | Error: type mismatch: got (Array constructor[0..4, int]) but expected 'FArray[int]' |
| 22:44:15 | Varriount | Araq: What part of the compiler needs to be touched to fix the bug involving casting to an openarray? semcast? |
| 22:44:33 | Araq | yup |
| 22:44:52 | Araq | you touched that once, right? |
| 22:45:16 | Varriount | Yeah. |
| 22:45:47 | Varriount | Araq: Your sure it's not another part of the compiler you want modified? Like some type-checking part or something? |
| 22:45:55 | Araq | what about that trailing slash bug? |
| 22:46:04 | Araq | Varriount: yeah, pretty much |
| 22:46:05 | Varriount | Working on it. |
| 22:46:09 | Araq | ok |
| 22:46:19 | Araq | why does it take so long? |
| 22:46:26 | Araq | it's a pretty simple fix? |
| 22:46:40 | Varriount | Araq: Because I keep getting interuppted at my computer. |
| 22:47:01 | Araq | the trick is to pull out the internet |
| 22:47:02 | * | mwbrown quit (Ping timeout: 240 seconds) |
| 22:47:19 | Araq | it's a gigantic waste of time |
| 22:47:27 | Varriount | I keep getting interuppted by my family. |
| 22:47:36 | Varriount | Not the internet, oddly enough. |
| 22:48:02 | Araq | hum interesting |
| 22:48:17 | flaviu | Araq: Do you have any more ideas on how to cast the array? |
| 22:49:30 | Araq | flaviu: cast it to ptr FArray |
| 22:50:26 | Araq | or use .emit in the converter's body ffs |
| 22:51:26 | Araq | but seriously |
| 22:51:45 | Araq | how hard is it to understand that arrays are a value type just like tuple? |
| 22:54:58 | Araq | array[left..right, PTree] # 2 PTree pointers, indexable so that all the tree symmetries can be exploited for small code size |
| 22:55:10 | Araq | now try that with Java |
| 22:56:03 | flaviu | `Tree[]`? |
| 22:56:53 | flaviu | Tree<T>[] actually, since this is generic. |
| 22:57:33 | Araq | yeah but this misses the point |
| 22:57:56 | Araq | you get an additional unnecessary indirection in Java |
| 22:58:16 | Araq | plus you can only index the array with integers |
| 22:58:32 | flaviu | Araq: There's a guy on Oracle working point #1 |
| 22:59:16 | Araq | after they denied there is a problem for decades |
| 22:59:56 | Araq | Java programmers are too stupid to use all these "new" features anyway |
| 23:00:01 | flaviu | wow, nearly two decades |
| 23:00:09 | flaviu | You're right, that is impressive |
| 23:00:33 | flaviu | Anyway, thats the main reason I moved away from java, along with type erasure |
| 23:00:46 | * | darkf joined #nimrod |
| 23:04:28 | flaviu | adoniscik: Ok, got it to work without any gimmicks and without undefined behaivior |
| 23:04:35 | flaviu | https://gist.github.com/27d152172a4c26b804c3 |
| 23:04:50 | adoniscik | aha, thanks, let me check |
| 23:05:30 | * | superfunc joined #nimrod |
| 23:06:21 | Araq | seriously? boxing? :P |
| 23:07:58 | flaviu | Isn't the caller of a converter responsible for setting up the memory for the output? |
| 23:08:53 | Araq | no, that's the compiler's job |
| 23:09:03 | flaviu | There isn't any way for the caller to know the size of the output here, but it allocates space for 1 T, which causes problems because the input array is more than one T |
| 23:09:29 | flaviu | Araq: Well, the compiler sets up the memory for the caller without the programmer worrying about it |
| 23:12:19 | Araq | oh come on now |
| 23:12:32 | Araq | you use .unchecked and then don't know what it does |
| 23:13:15 | Araq | some features are designed for the people who know what they are doing |
| 23:13:35 | flaviu | Doesn't unchecked just turn off bounds checking? |
| 23:13:44 | Varriount | Araq: Should I avoid string copies at all costs? |
| 23:14:52 | Araq | flaviu: well as you noted the compiler still thinks the size is "correct" and allocates that amount for you |
| 23:15:13 | Varriount | Or more directly: Can I just use removeTrailingDirSep to create a copy of a path marked for exclusion that lacks trailing directory seperators? |
| 23:15:53 | Araq | you can do that but then some fool uses cmpPath in a newly created benchmark and people will say "oh nim sux" |
| 23:16:09 | Araq | it's your choice |
| 23:16:12 | Varriount | Araq: This isn't in cmpPath, this is in the compiler code. |
| 23:16:30 | Araq | well but it should be in cmpPath |
| 23:17:04 | Araq | in the compiler it's fine, this is never in the critical path |
| 23:17:20 | Varriount | But aren't /foo and /foo/ technically referring to different things? |
| 23:17:57 | Araq | I can't see how |
| 23:18:20 | Araq | no software that I use distringuishes between these two |
| 23:21:37 | Araq | flaviu: don't miss your chance to correct me |
| 23:26:46 | Araq | speaking of which ... what does ssh:/hg@hg//hg/foo/bar mean? |
| 23:27:12 | Varriount | Araq: What should cmpPath("%HOME%/AppData", "C:/Users/Clay/AppData") return when %HOME% is "C:/Users/Clay"? |
| 23:27:27 | Araq | why the double slashes? |
| 23:27:52 | Araq | Varriount: something. don't expand environment variables in cmpPath |
| 23:28:23 | Araq | and as usual the effect system helps here |
| 23:28:43 | Araq | expanding env vars produces the FReadEnv effect |
| 23:28:54 | Araq | so ... this is a breaking change :P |
| 23:31:03 | Araq | Varriount: keep in mind that cmpPath is for sorting. it doesn't compare whether the files are the same, it doesn't follow symlinks, it doesn't expand env vars, it doesn't translate into DOS's 8.3 format ... |
| 23:31:23 | * | othello quit (Quit: Page closed) |
| 23:31:53 | * | mwbrown joined #nimrod |
| 23:33:14 | * | linkmonitor quit (Quit: Page closed) |
| 23:37:12 | flaviu | Araq: I was too busy getting chocolate chip cookies to eat |
| 23:38:17 | Araq | well you can still tell me how dumb I am |
| 23:38:25 | flaviu | Firefox uses those rules |
| 23:39:09 | flaviu | Oh, sorry, wrong rules |
| 23:39:29 | flaviu | Well, the http server for the llvm blog uses the rules you were referring to |
| 23:39:38 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 23:40:26 | * | xenagi joined #nimrod |
| 23:42:21 | flaviu | ex, look at http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html and at http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html/ |
| 23:46:09 | flaviu | It seems that if you add a slash where there wasn't one, you get an error. However, if you remove the trailing slash, you get redirected. Although I don't know if this is because firefox is messing around with the URL |
| 23:47:42 | Araq | paths are not urls ... |
| 23:48:22 | flaviu | They are URIs, and therefore behave by the same rules |
| 23:48:39 | Araq | URIs came much later |
| 23:49:08 | Araq | you can't pretend every path is an URL when it's clearly not |
| 23:49:21 | flaviu | They are referring to different things: /foo is a file. /foo/ is a dir |
| 23:49:30 | flaviu | /foo != /foo/ |
| 23:49:37 | Araq | cd /foo |
| 23:49:44 | Araq | oops, this works |
| 23:49:56 | Araq | stupid cd |
| 23:49:58 | flaviu | Araq: 1 sec, I can't figure out the notation I want to use |
| 23:50:04 | flaviu | That was incomplete |
| 23:50:28 | flaviu | /foo => /foo/ |
| 23:50:28 | flaviu | /foo/ !=> /foo |
| 23:51:05 | flaviu | /foo can mean /foo/; /foo/ can never mean /foo |
| 23:52:20 | flaviu | Therefore, the only correct solution is to check that /foo is a dir, and then your reasoning holds |
| 23:53:04 | flaviu | But that takes time, and the only way to be sure that foo is a dir without checking is to stick to the convention `/foo/` |
| 23:53:20 | Araq | that's a sideeffect |
| 23:53:31 | Araq | cmpPath has no effects |
| 23:56:44 | flaviu | So you're required to follow the URI rules then |
| 23:57:13 | Araq | /foo vs /foo/ should not depend on the HD's contents, that is insane |
| 23:57:59 | flaviu | If you can't assume that the trailing slashes are correct, that is the only way to achieve reasonable results |
| 23:58:05 | Araq | maybe you should read cmpPath's docs |
| 23:58:19 | Araq | it does a case insensitive comparison on windows |
| 23:58:50 | Araq | do you think this "follows URI rules"? |
| 23:59:21 | Araq | and again, why should it, URI rules are bullshit |
| 23:59:35 | * | saml_ joined #nimrod |