| 00:01:22 | * | BitPuffin joined #nimrod |
| 00:07:03 | Varriount | Araq: Are there other nimrod projects/tools that need to be tested? |
| 00:08:17 | Araq | what do you test? |
| 00:13:16 | * | boydgreenfield joined #nimrod |
| 00:17:26 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 00:17:51 | * | Francisco joined #nimrod |
| 00:18:10 | * | Fr4n quit (Ping timeout: 256 seconds) |
| 00:21:36 | * | mbenadda_ quit (Quit: Be back later ...) |
| 00:22:39 | Varriount | Araq: Well, I can test whether certain tools/projects will compile with a Nimrod version. |
| 00:25:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:29:44 | Araq | well test the official babel packages |
| 00:31:27 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 00:32:37 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 00:37:08 | * | Francisco quit (Quit: Leaving) |
| 00:37:49 | * | Jehan_ quit (Quit: Leaving) |
| 01:13:09 | * | superfunc joined #nimrod |
| 01:26:12 | * | tinAndi quit (Quit: ChatZilla 0.9.91 [Firefox 32.0.3/20140923175406]) |
| 01:31:17 | flaviu | Varriount: Did my PR break something? |
| 01:31:55 | flaviu | oh, I see the irclogs |
| 01:33:02 | flaviu | Araq: Since I was the first one to complain, I think I've been the only one to use that |
| 01:33:25 | flaviu | Anyway, doesn't newstring add a trailing zero anyway? |
| 01:43:17 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 01:52:08 | * | boydgreenfield joined #nimrod |
| 01:52:20 | boydgreenfield | Where should I be looking for the latest async docs btw? |
| 02:15:46 | * | Fr4n joined #nimrod |
| 02:33:37 | * | Trustable1 joined #nimrod |
| 02:36:25 | fowl | boydgreenfield, articles |
| 02:37:49 | * | Trustable quit (Ping timeout: 260 seconds) |
| 02:44:26 | * | flaviu quit (Ping timeout: 255 seconds) |
| 02:50:21 | * | Trustable1 quit (Quit: Leaving) |
| 03:37:34 | boydgreenfield | fowl: … sorry, I wasn’t asking to be pedantic or imply they *should* exit. I just thought I’d heard somebody mention updated async docs, but can’t for the life of me find them on Github or nimrod-lang. Link? |
| 03:46:07 | fowl | i know of none |
| 03:46:34 | fowl | last i looked on build.nimrod-code.org there were none |
| 03:52:52 | * | superfunc quit (Ping timeout: 246 seconds) |
| 03:56:23 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:03:44 | * | boydgreenfield joined #nimrod |
| 04:09:50 | * | q66[lap] joined #nimrod |
| 04:10:51 | * | q66[lap] quit (Client Quit) |
| 04:18:49 | * | kemet joined #nimrod |
| 04:20:30 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:02:01 | * | johnsoft quit (Ping timeout: 260 seconds) |
| 05:02:31 | * | johnsoft joined #nimrod |
| 05:08:17 | * | xenagi joined #nimrod |
| 05:21:49 | * | xenagi quit (Quit: Leaving) |
| 05:34:39 | * | boydgreenfield joined #nimrod |
| 05:34:42 | boydgreenfield | fowl: Got it. Ok thanks. |
| 05:35:17 | * | fowl quit (Ping timeout: 264 seconds) |
| 05:45:20 | * | BitPuffin quit (Ping timeout: 256 seconds) |
| 05:51:51 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:54:57 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) |
| 05:57:50 | * | gokr_ quit (Ping timeout: 244 seconds) |
| 05:57:52 | * | gokr joined #nimrod |
| 06:00:20 | * | gokr quit (Remote host closed the connection) |
| 06:00:36 | * | gokr joined #nimrod |
| 06:01:28 | * | gokr quit (Remote host closed the connection) |
| 06:02:21 | * | gokr joined #nimrod |
| 06:42:38 | * | gokr_ joined #nimrod |
| 06:43:59 | * | gokr quit (Ping timeout: 245 seconds) |
| 06:46:47 | * | fowl joined #nimrod |
| 06:57:05 | * | bjz quit (Ping timeout: 256 seconds) |
| 07:07:41 | * | gokr joined #nimrod |
| 07:07:41 | * | gokr_ quit (Read error: Connection reset by peer) |
| 07:22:17 | * | Demos quit (Read error: Connection reset by peer) |
| 07:22:17 | * | gokr quit (Ping timeout: 244 seconds) |
| 07:25:10 | * | gokr joined #nimrod |
| 07:26:53 | * | gokr_ joined #nimrod |
| 07:28:00 | * | gokr quit (Read error: Connection reset by peer) |
| 07:28:57 | * | gokr joined #nimrod |
| 07:29:20 | * | gokr quit (Remote host closed the connection) |
| 07:30:13 | * | gokr joined #nimrod |
| 07:30:25 | * | Fr4n quit (Ping timeout: 260 seconds) |
| 07:30:51 | * | boydgreenfield joined #nimrod |
| 07:31:21 | * | gokr_ quit (Ping timeout: 244 seconds) |
| 07:36:01 | * | Fr4n joined #nimrod |
| 07:41:32 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:52:18 | * | uber quit (Changing host) |
| 07:52:18 | * | uber joined #nimrod |
| 07:52:28 | * | gokr quit (Remote host closed the connection) |
| 07:53:11 | * | gokr joined #nimrod |
| 08:04:53 | Varriount | Araq, dom96: The csources devel branch is broken for Windows x64 (and possibly x32) |
| 08:05:25 | Varriount | I don't know how to generate csources - I get a config error when running 'koch csources' |
| 08:05:42 | Varriount | Error: unhandled exception: format string: key not found: mingw [EInvalidValue] |
| 08:13:52 | * | boydgreenfield joined #nimrod |
| 08:17:25 | * | gokr quit (Remote host closed the connection) |
| 08:18:03 | * | gokr joined #nimrod |
| 08:26:23 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 08:37:40 | * | bjz joined #nimrod |
| 08:51:39 | * | johnsoft quit (Ping timeout: 244 seconds) |
| 08:51:58 | * | johnsoft joined #nimrod |
| 09:32:39 | * | bjz quit (Read error: Connection reset by peer) |
| 09:33:09 | * | bjz joined #nimrod |
| 10:06:20 | * | Jesin quit (Quit: Leaving) |
| 10:08:24 | * | Jesin joined #nimrod |
| 10:13:52 | * | darkf_ joined #nimrod |
| 10:17:31 | * | darkf quit (Ping timeout: 265 seconds) |
| 10:47:50 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 10:48:05 | * | johnsoft joined #nimrod |
| 10:58:27 | * | BlaXpirit joined #nimrod |
| 11:06:29 | * | darkf_ is now known as darkf |
| 11:10:09 | * | gokr_ joined #nimrod |
| 11:10:25 | * | gokr quit (Ping timeout: 244 seconds) |
| 11:28:34 | * | q66[lap] joined #nimrod |
| 11:31:49 | * | q66[lap] quit (Read error: Connection reset by peer) |
| 11:32:28 | * | q66[lap] joined #nimrod |
| 11:33:04 | * | gokr joined #nimrod |
| 11:38:45 | gokr | Varriount: Looking for build hosts? |
| 11:41:07 | * | Francisco joined #nimrod |
| 11:44:17 | * | Fr4n quit (Ping timeout: 264 seconds) |
| 11:49:42 | * | q66 joined #nimrod |
| 11:53:14 | * | Fran__ joined #nimrod |
| 11:55:37 | * | Francisco quit (Ping timeout: 255 seconds) |
| 11:57:00 | * | Trustable joined #nimrod |
| 11:57:35 | * | kemet joined #nimrod |
| 12:21:35 | * | gokr quit (Quit: Leaving.) |
| 12:22:36 | * | BitPuffin joined #nimrod |
| 12:26:45 | * | kemet quit (Remote host closed the connection) |
| 12:41:11 | Araq | Varriount: you should really know how to fix that by now ;-) |
| 12:44:38 | * | kemet joined #nimrod |
| 12:44:44 | * | kemet quit (Remote host closed the connection) |
| 12:54:24 | * | gokr joined #nimrod |
| 12:54:24 | * | gokr_ quit (Read error: Connection reset by peer) |
| 12:55:37 | Trustable | Hi Araq. How are you doing? What's the status of Nim 0.10.0 or Nimrod 0.9.8? Maybe we should have a small to do list on the wiki, so people can see status and how to help. |
| 13:02:34 | Araq | Trustable: well there are a couple of bugs I'm working on |
| 13:02:53 | Araq | but the major thing that keeps us from releasing is that the new website ain't ready |
| 13:03:02 | Araq | dom96 is working on it |
| 13:05:36 | * | Dispatch joined #nimrod |
| 13:05:52 | Araq | Trustable: can you look into that JS codegen regression? |
| 13:06:49 | Araq | there is web/babelpackagelist.nim which is translated to JS and then make part of the website |
| 13:06:55 | Trustable | Araq: Which issue? |
| 13:07:06 | Araq | has no bug report |
| 13:07:31 | Araq | http://nimrod-lang.org/lib.html |
| 13:07:52 | Araq | http://nimrod-lang.org/lib.html#babel |
| 13:08:06 | Araq | "If you are reading this you are missing babelpkglist.js or have javascript disabled in your browser." |
| 13:08:20 | Araq | but it works, this error message is wrong |
| 13:08:32 | Araq | the listing of babel packages itself works |
| 13:09:00 | Araq | so, please try 0.9.4 with this .nim file and see if it never worked or if we have some regression somewhere |
| 13:10:51 | Araq | if it's too hard, at least create a bug report about it please |
| 13:15:46 | NimBot | Araq/Nimrod bigbreak 3939e67 Clay Sweetser [+0 ±2 -0]: Fix #1599... 3 more lines |
| 13:15:46 | NimBot | Araq/Nimrod bigbreak ef47a23 Andreas Rumpf [+0 ±2 -0]: Merge pull request #1604 from Varriount/fix-1599... 2 more lines |
| 13:16:20 | NimBot | Araq/Nimrod bigbreak a8a9dd6 Varriount [+1 ±2 -0]: Fix #1561 |
| 13:16:20 | NimBot | Araq/Nimrod bigbreak 51c8758 Andreas Rumpf [+1 ±1 -0]: Merge pull request #1589 from Varriount/fix-1561... 2 more lines |
| 13:49:33 | * | AFKMorpork is now known as AMorpork |
| 13:58:55 | Trustable | Araq: "If you are reading this you are missing babelpkglist.js or have javascript disabled in your browser." is only visible when JS is off. What is the problem? |
| 14:00:38 | * | gokr1 joined #nimrod |
| 14:02:10 | * | darkf quit (Quit: Leaving) |
| 14:11:45 | * | Dispatch quit (Quit: Page closed) |
| 14:38:31 | * | irrequietus joined #nimrod |
| 14:57:29 | * | q66[lap] quit (Read error: Connection reset by peer) |
| 14:59:53 | * | q66[lap] joined #nimrod |
| 15:06:52 | * | Fran__ quit (Ping timeout: 240 seconds) |
| 15:28:59 | * | flaviu joined #nimrod |
| 15:58:58 | * | untitaker quit (Ping timeout: 250 seconds) |
| 16:05:40 | * | untitaker joined #nimrod |
| 16:10:14 | * | Jehan_ joined #nimrod |
| 16:15:11 | * | gokr_ joined #nimrod |
| 16:17:19 | * | gokr quit (Ping timeout: 244 seconds) |
| 16:27:45 | * | Stefan_Salewski joined #nimrod |
| 16:27:57 | Stefan_Salewski | I am just reading the nice Goran Krampe OO tutorial part 1. |
| 16:28:10 | Stefan_Salewski | No idea what sentence "If you do initialization separately you can also use `new(lightHolder)`" means. |
| 16:28:20 | Stefan_Salewski | Please give an example. |
| 16:28:25 | * | Stefan_Salewski quit (Client Quit) |
| 16:29:59 | * | irrequietus quit () |
| 16:45:45 | * | Matthias247 joined #nimrod |
| 17:15:53 | Araq | Trustable: well it is *always* visible for me (Firefox) |
| 17:16:32 | * | silven quit (*.net *.split) |
| 17:19:09 | Araq | interesting |
| 17:19:21 | Araq | it's browser specific, it works in chrome |
| 17:20:03 | * | silven joined #nimrod |
| 17:25:35 | Jehan_ | Araq: One thing that's still an issue with method dispatch is that it does incorrect devirtualization at times. That will require further digging, but is separate from the other fixes. |
| 17:27:45 | * | Varriount|Mobile joined #nimrod |
| 17:29:17 | Jehan_ | It looks like it happens if the call site sees only part of the declarations of the other method. |
| 17:29:41 | Varriount|Mobile | Gokr: Yes, I'm looking for build hosts. Are you offering any? |
| 17:31:26 | Jehan_ | Eh, implementations, not declarations. |
| 17:31:26 | Varriount|Mobile | Jehan_: Regarding some of your posts on the forum, what exactly are type templates and generic modules? |
| 17:31:40 | Jehan_ | type templates are templates that return types. |
| 17:32:02 | Jehan_ | Currently not possible because the parser barfs on template t = object ... |
| 17:32:20 | Jehan_ | generic modules: See OCaml or the example I gave. |
| 17:32:34 | * | q66[lap] quit (Ping timeout: 250 seconds) |
| 17:32:34 | * | q66 quit (Ping timeout: 250 seconds) |
| 17:34:36 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 17:34:55 | * | Varriount|Mobile joined #nimrod |
| 17:35:41 | Jehan_ | Basically, modules that are paramterized by other modules. |
| 17:36:10 | * | q66 joined #nimrod |
| 17:36:18 | * | q66[lap] joined #nimrod |
| 17:37:32 | Varriount|Mobile | Jehan_: Ah, very interesting. So generic modules are essentially modules that can be instantiated with type parameters that their contents can make use of. |
| 17:38:06 | Jehan_ | Instantiated with modules, which can have anything that a module can have: type parameters, constants, variables, functions ... |
| 17:38:09 | Varriount|Mobile | I wonder what Araq thinks of them... |
| 17:38:28 | Jehan_ | The primary benefit over a proc foo[…]() is that the parameter list doesn't get blown up. |
| 17:39:31 | Jehan_ | In my example, everything is parameterized by a type and three constants, two of them being constants of the parameter type. |
| 17:39:40 | Varriount|Mobile | Sounds complicated to implement though, considering how I think modules are currently represented in the compiler. |
| 17:40:16 | Jehan_ | That'd require proc `*`[T, n: static[int], zero: static[T], one: static[T]]( ….) = ... |
| 17:40:26 | Jehan_ | And that repeated for every single procedure declaration. |
| 17:40:56 | Jehan_ | Leaving aside that [T, something: static[T]] doesn't currently work, I think. |
| 17:41:28 | Araq | Varriount|Mobile: I have no opinion on them yet. but I think zahary's mimic types sound more useful |
| 17:41:31 | Jehan_ | Conversely, generic modules are really overkill if you just want an OrderedSet[T]. |
| 17:41:31 | Araq | bbl |
| 17:42:04 | Varriount|Mobile | Araq: I have yet to actually see mimic types in action. :/ |
| 17:42:14 | Jehan_ | I have no idea what these mimic types are. :) |
| 17:42:20 | Varriount|Mobile | ^ |
| 17:43:08 | * | will joined #nimrod |
| 17:44:52 | will | Araq: the problem with babelpackagelist.nim is that it seems to be trying to fetch http://build.nim-lang.org/packages?callback=gotPackageList whereas before it was checking: http://build.nimrod-lang.org/packages?callback=gotPackageList |
| 17:51:36 | flaviu | Araq: Re https://github.com/Araq/Nimrod/pull/1618, doesn't newstring(24) effectively allocate 25 bytes, with the last being zero for the whole 0-cost cstring conversion? |
| 17:54:33 | flaviu | dom96: I hear that you do the website stuff, perhaps you can do a 301 redirect to the new website to force people to move? https://support.google.com/webmasters/answer/93633?hl=en seems to be relevant, I'm sure it has some SEO importance too, as well as fixing the gotPackageList bug |
| 17:58:46 | * | Var|Mobile joined #nimrod |
| 17:59:30 | * | jorma joined #nimrod |
| 17:59:50 | * | jorma is now known as jorma2 |
| 18:01:36 | * | Varriount|Mobile quit (Ping timeout: 250 seconds) |
| 18:01:49 | jorma2 | hi, I wonder what would be the right way of reading a sequence of items from socket without unnecessary copies? Socket recv takes a pointer, so can I somehow get a pointer to memory backing seq[T] e.g.? |
| 18:06:25 | will | jorma2: I'm not familiar with the socket api, but yout can take the addr of the 0th element in the seq to get a ptr T |
| 18:06:49 | * | Karpax joined #nimrod |
| 18:07:32 | * | Karpax quit (Client Quit) |
| 18:11:08 | * | brson joined #nimrod |
| 18:14:15 | * | vendethiel- joined #nimrod |
| 18:14:16 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 18:16:05 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 18:18:30 | dom96 | flaviu: It's not Nim *yet* |
| 18:19:13 | jorma2 | will: thanks. I was getting 'expression has no address' errors trying that, but I've missed that the input sequence needs to be declared 'var' in order for that to work |
| 18:19:29 | dom96 | jorma2: You should give it an address to a string. |
| 18:20:35 | dom96 | flaviu: The proper fix is to make build.nim-lang.org to work. |
| 18:20:42 | dom96 | s/to// |
| 18:21:14 | jorma2 | dom96: but the data I'm receiving is not strings. Its 16-bit complex numbers |
| 18:22:09 | dom96 | jorma2: A string can hold that I think. |
| 18:22:46 | dom96 | You could pass the address to an array of ints perhaps |
| 18:23:00 | dom96 | you shouldn't be using seq[T] in any case |
| 18:23:21 | dom96 | array[len, T] |
| 18:23:37 | dom96 | recv(addr arr[0], len) or something like that |
| 18:23:41 | dom96 | gotta go bye |
| 18:26:54 | * | gokr_ quit (Ping timeout: 245 seconds) |
| 18:33:37 | jorma2 | anyone know why it would be bad to take address to data in seq? Is the seq not guaranteed to be contiguous in memory? |
| 18:33:59 | Jehan_ | jorma2: It is, but when the seq gets resized, it may move in memory. |
| 18:37:37 | jorma2 | Jehan_: thanks, then seq seems like a better fit for my needs, since I really don't want to limit the API to using only arrays for passing around data |
| 18:39:14 | Jehan_ | jorma2: Be advised though that seqs to get initialized to zero when allocated, so that you may lose the benefit from doing zero-copying sends and receives. |
| 18:39:48 | Jehan_ | If you want to be that low-level, then alloc() and dealloc() may be the right choice instead. |
| 18:40:43 | flaviu | jorma2: unchecked arrays? They work great for anything but pointers, and you won't be sending pointers over the network. |
| 18:41:17 | jorma2 | Jehan_: Ok, I see. I think this is acceptable since I'll just allocate seq up front and then receive a buffer full of data to it multiple times. It's just that the buffer size is user configurable, so I rather use builtin dynamically allocated array (i.e., sequence) |
| 18:44:21 | * | flaviu quit (Remote host closed the connection) |
| 18:45:01 | * | flaviu joined #nimrod |
| 18:45:16 | * | flaviu quit (Remote host closed the connection) |
| 18:48:26 | * | Fran__ joined #nimrod |
| 18:48:49 | * | flaviu joined #nimrod |
| 18:50:22 | * | Dispatch joined #nimrod |
| 18:50:40 | * | Fran__ is now known as Francisco |
| 18:54:28 | * | Dispatch quit (Ping timeout: 246 seconds) |
| 18:58:36 | * | Dispatch joined #nimrod |
| 19:18:46 | Varriount | Hello Dispatch |
| 19:19:15 | Dispatch | Hi |
| 19:32:15 | Dispatch | Does anyone have an example of loading a png (to use as an opengl texture)? |
| 19:32:38 | Dispatch | I looked at libpng and an example would be helpful.. |
| 19:34:51 | Varriount | Dispatch: I *think* I have two |
| 19:34:58 | Varriount | Dispatch: Let me check. |
| 19:35:05 | Dispatch | great, thx |
| 19:35:31 | Varriount | Dispatch: I followed an OpenGL C tutorial a while ago, using Nim instead of C. |
| 19:36:15 | Varriount | Dispatch: There are wrappers for ILU and SOIL on github |
| 19:37:26 | Varriount | Dispatch: |
| 19:37:28 | Varriount | https://gist.github.com/Varriount/d29b32ed6dffdec86c0e |
| 19:37:53 | Varriount | That requires either the DevIL wrapper, or the FreeImage wrapper. |
| 19:38:18 | Varriount | Plus the OpenGL wrapper, of course. |
| 19:38:27 | Dispatch | ok thx |
| 19:38:38 | Dispatch | I got opengl working with a raw image |
| 19:39:03 | Varriount | Dispatch: If you want, I can post the rest of the tutorial code. I don't know if it still works, but it should give you an idea. |
| 19:39:19 | Dispatch | but it would be nice to not have to convert all the images. |
| 19:39:50 | Dispatch | I think your example will work |
| 19:40:18 | Varriount | Araq: How would you feel about a manually invoked builder that generates and uploads csources? |
| 19:46:47 | * | Mat3 joined #nimrod |
| 19:46:50 | Mat3 | hello |
| 19:47:03 | * | Var|Mobile joined #nimrod |
| 19:49:10 | Varriount | O_o |
| 19:49:32 | * | Var|Mobile quit (Client Quit) |
| 19:50:42 | * | Francisco quit (Ping timeout: 244 seconds) |
| 19:50:49 | * | jorma2 quit (Ping timeout: 246 seconds) |
| 19:54:57 | * | gokr_ joined #nimrod |
| 19:56:54 | Varriount | Hi gokr_ |
| 19:57:07 | * | Francisco joined #nimrod |
| 20:06:33 | Jehan_ | Varriount: Wouldn't that blow up the csources repository quickly? |
| 20:08:46 | Varriount | Jehan_: I don't mean an automatic build, I mean a manual one. |
| 20:08:58 | Jehan_ | Varriount: Ah, I see. |
| 20:09:06 | Varriount | The build software I'm using (buildbot) has facilities for users to invoke manual builds |
| 20:09:53 | Varriount | It would be automatic in the sense that we wouldn't have to worry about setting up a clean Nimrod repository. |
| 20:11:37 | Varriount | Araq: Does it matter what architecture I generate csources under? If so, should I generate it under 32-bit, 64-bit, or both? |
| 20:12:32 | * | irrequietus joined #nimrod |
| 20:14:49 | * | bjz quit (Ping timeout: 245 seconds) |
| 20:16:01 | Varriount | oh, and csources generation appears to be broken - the generated files are giving me linker errors when I build them. |
| 20:16:12 | Varriount | (on devel branch) |
| 20:17:46 | * | Dispatch quit (Ping timeout: 246 seconds) |
| 20:18:36 | Jehan_ | Varriount: csources will generate cross-compiled C sources for all OS/CPU combinations that it's configured for. |
| 20:19:12 | Jehan_ | That's what the build/c_code/#_# directories are. |
| 20:19:28 | * | hopla joined #nimrod |
| 20:20:19 | hopla | hello all. I tried to compile this program with no sucess:type Echoable = generic x\n echo x\nproc d[Echoable](x:Echoable):\n echo x |
| 20:20:25 | Jehan_ | It should in principle not matter one whit where you generate them. |
| 20:20:26 | hopla | I am not sure how to format it |
| 20:20:46 | hopla | I got a type mismatch error (I am a newbie) |
| 20:20:57 | * | bjz joined #nimrod |
| 20:21:01 | Jehan_ | hopla: generics are an experimental feature, they may not work. |
| 20:21:16 | hopla | Is that a bug for this one? |
| 20:21:23 | hopla | Or is it really a typo? |
| 20:21:25 | * | Dispatch joined #nimrod |
| 20:21:59 | gokr1 | Evening |
| 20:22:25 | hopla | Basically, I was not able to use echo in a template function. |
| 20:22:54 | gokr1 | Varriount: Can you tell me a bit more about host needs? |
| 20:22:59 | hopla | (generic I mean) |
| 20:23:12 | gokr1 | Is it for building Nim and stdlibs on various platforms or? |
| 20:24:57 | gokr1 | For us Ubuntu LTS versions and CentOS 6.4+ versions are interesting. And of course Windows and OSX. |
| 20:25:14 | flaviu | Should't parseopt2 interpret `'-1'` as a value `-1`, not a short option? |
| 20:25:34 | gokr1 | We are most probably building ourselves too - but I guess having the buildbot do these platforms would catch "regressions" early etc. |
| 20:25:46 | gokr1 | And of course - like to chip in. |
| 20:28:21 | * | onionhammer quit (Quit: WeeChat 0.4.3) |
| 20:29:14 | fowl | hopla, paste it somewhere please |
| 20:29:16 | * | OrionPK quit (Remote host closed the connection) |
| 20:29:35 | * | onionhammer joined #nimrod |
| 20:30:19 | hopla | fowl: OK. also. can echo be used with a generic parameter? I am not able to do so even if it is then instantiated with a string. The generic proc does not compile |
| 20:33:35 | flaviu | hopla: It's supposed to work, but https://github.com/Araq/Nimrod/issues?q=is%3Aissue+is%3Aopen+generic+label%3AGenerics |
| 20:34:07 | flaviu | Unfortunate, but that's the way it is for now |
| 20:35:11 | Jehan_ | hopla: Looking at your code closer, I think there's a misunderstanding in how you think the "generic" keyword works. |
| 20:35:25 | Jehan_ | "generic" provides a type signature, it does not contain code. |
| 20:36:42 | * | bjz quit (Ping timeout: 256 seconds) |
| 20:39:53 | fowl | proc foo[T] (someValue: T) = echo("my value: ", someValue) |
| 20:41:29 | * | rpag joined #nimrod |
| 20:46:20 | * | brson quit (Ping timeout: 256 seconds) |
| 20:47:10 | hopla | fowl: proc foo[T] (someValue: T) = echo(someValue) does not work |
| 20:47:26 | hopla | fowl: while "echo 2" works |
| 20:48:01 | * | brson joined #nimrod |
| 20:48:14 | fowl | well do you get an error? |
| 20:48:34 | fowl | and please paste your code |
| 20:48:44 | fowl | http://gist.github.com |
| 20:49:29 | hopla | fowl: https://gist.github.com/anonymous/9a5065de6b3e51a94d5e |
| 20:49:50 | fowl | this syntax is incorrect |
| 20:49:57 | fowl | the first line should end with "=", not ":" |
| 20:50:13 | hopla | argh |
| 20:50:57 | hopla | I was confused by the error message. Thanks. Pretty newbie question :-) |
| 20:52:17 | hopla | fowl: so, generic are like in C++? No semantic checks are done except when using the typeclasses? Basically, I can feed a generic with everything that compiles? |
| 20:53:03 | flaviu | hopla: You don't need to use the `generic` thing, you can just omit all but return types from your functions. |
| 20:53:25 | flaviu | Unless you want the added structure that brings |
| 20:53:39 | fowl | hopla, yes it is similar to c++, they are checked when they are instantiated |
| 20:54:02 | hopla | fowl: ok! |
| 20:54:03 | fowl | flaviu, thats a bit misleading, proc(x) is still generic |
| 20:54:20 | flaviu | Yep, it doesn't return anything |
| 20:54:31 | fowl | even if it did |
| 20:54:38 | fowl | it would be generic |
| 20:54:53 | flaviu | Yes, it would be |
| 20:55:35 | flaviu | hopla: not having a return type doesn't mean "infer this type", it means "this returns nothing". Thanks fowl for pointing that out |
| 20:55:52 | Araq | hopla: there is some symbol lookup checking done, but no type checking. |
| 20:56:09 | Varriount | gokr1: What kind of needs? All thats needed are the resources to compile Nimrod. |
| 20:56:34 | Araq | Varriount: manually triggering stuff is perfectly fine |
| 20:56:45 | hopla | thanks for the clarification. Also, since I discovered nim two days ago, is there a plan to support vectors (clang/gcc like) and also simd intrinsics? |
| 20:57:24 | gokr1 | Varriount: So, is the idea to build on different Linux platforms (among others)? |
| 20:57:33 | flaviu | hopla: I'm not sure what you mean by vectors. Seqs are the resizable arrays |
| 20:57:34 | Varriount | gokr1: Yes. |
| 20:57:51 | hopla | flaviu: simd vectors |
| 20:57:58 | Jehan_ | Araq: Just so you know, there's still some stuff that I'll attach to the method PR. |
| 20:57:59 | Varriount | gokr1: Currently the Linux build bots are hosted on whatever server hosts the website (I think) |
| 20:58:12 | fowl | someone wrote simd wrappers iirc |
| 20:58:15 | Varriount | And I host the Windows build bots on my desktop computer. |
| 20:58:16 | Jehan_ | Going down a rabbit hole. |
| 20:58:38 | Araq | Jehan_: like what? |
| 20:58:43 | hopla | fowl: where? I want that :-) |
| 20:59:00 | Varriount | But we don't have any builders for Mac OSX, or any of the BSD's |
| 20:59:03 | gokr1 | I could also set up on some local box here at home. Got silly machines that I don't know what to use for :) |
| 20:59:18 | Jehan_ | Araq: Fiddly stuff surrounding dispatcher creation. |
| 20:59:27 | Varriount | Araq: What should I do to fix csources? |
| 20:59:52 | gokr1 | But... what stops us from using Vagrant to run various platforms virtually? |
| 21:00:05 | gokr1 | (which is why I asked about vagrant earlier) |
| 21:00:11 | Varriount | gokr1: I don't know, I haven't heard of Vagrant. |
| 21:00:25 | gokr1 | It's basically a tool that scripts virtualbox. |
| 21:00:30 | gokr1 | headless. |
| 21:00:33 | fowl | hopla, i'm having trouble finding it |
| 21:00:44 | gokr1 | We use it to build on clean CentOS versions etc. |
| 21:00:58 | gokr1 | We run each build on a "clean box". |
| 21:01:12 | Araq | Varriount: just add --var:mingw=mingw32 or even --var:mingw=none since it doesn't matter |
| 21:01:13 | flaviu | Compilation is 1 cpu only, so 1 buildbot per core, that should work |
| 21:01:37 | fowl | buildbots, goooooo! |
| 21:01:54 | Varriount | Araq: I got past the format error, I'm now just getting linker errors with the generated code. Will that fix it? |
| 21:02:06 | gokr1 | We have had on our todo to setup a Jenkins (perhaps Buildbot is nicer?) at our cloud provider. We could use that one for the Linuxes I mentioned. |
| 21:02:46 | Araq | Varriount: not sure what you mean. it generates a build.sh that works |
| 21:02:47 | Jehan_ | Araq: For example, trying to figure out why resultPos is not always filled in for a method. |
| 21:02:48 | Varriount | gokr1: I've not had good experiences with Jenkins web interface, and Araq forbade me to use anything Java based. |
| 21:02:55 | gokr1 | Hehe! |
| 21:03:07 | flaviu | werker provides free VMs for builds, as long as it takes < 15 mins. I use it for nimrod-by-example |
| 21:03:08 | Varriount | Araq: c_code\1_2\nimrod.o:nimrod.c:(.text+0x15e6): undefined reference to `stdlib_cpui |
| 21:03:08 | Varriount | nfoDatInit' |
| 21:03:14 | Jehan_ | May have to do with just having a method prototype instead of a method definition, but not sure. |
| 21:03:30 | flaviu | I think they have experimental windows VMs, but I'm not sure if those are for public use yet... |
| 21:04:02 | Varriount | flaviu: 15 minutes is cutting it close. |
| 21:04:02 | Araq | flaviu: the test suite runs longer than 15 minutes, I think |
| 21:04:25 | flaviu | GC tests could be cut off though, those only need to be run when the GC changes |
| 21:04:28 | hopla | fowl: the emit pragma seems to be able to work around though I am not sure what should be the type of the variable if I want to use for example _mm_add_ps. Also, the alignment needs to be correct |
| 21:05:02 | gokr1 | So... what platforms do you have today you said? |
| 21:05:21 | flaviu | gokr1: http://build.nimrod-lang.org/ |
| 21:05:38 | Varriount | gokr1: Windows and Linux, 64 & 32 bit for each. |
| 21:05:42 | flaviu | see the grid in the top right, orange means it's built on that at least once, green means currently active. |
| 21:05:58 | Varriount | flaviu: That's not much help - my builders aren't active. |
| 21:06:06 | gokr1 | So Linux is just "Linux" - no distinction? |
| 21:06:24 | Varriount | gokr1: Er, thats what will be the old build page. |
| 21:06:34 | Varriount | I haven't finished setting up the new builder |
| 21:06:57 | gokr1 | Right - but the idea is to build specifically for distro and version thereof? |
| 21:07:35 | Varriount | I guess? |
| 21:07:37 | Araq | gokr1: no. |
| 21:07:55 | Araq | one Linux per cpu target |
| 21:08:02 | Araq | distro is irrelevant |
| 21:08:05 | Varriount | Araq: This is what I'm getting when I run build64.bat -> https://gist.github.com/Varriount/074b99358632e80aa651 |
| 21:08:21 | gokr1 | Araq: As in... version of gcc etc? |
| 21:08:40 | Araq | Varriount: yeah but I simply forgot to push the latest build.bat scripts |
| 21:08:55 | Araq | this shouldn't happen when you generate them |
| 21:09:14 | Araq | gokr1: yes |
| 21:09:22 | * | gokr1 confused... |
| 21:09:41 | Varriount | gokr1: If it makes you feel any better, you're confusing me. |
| 21:10:48 | gokr1 | I am just asking what Linux platforms we want to build for. Araq says "just Linux", I guess one for x86_64, one for ppc64 etc. But... then I wonder about version of gcc etc. |
| 21:10:49 | flaviu | I think gokr1 wants to suggest testing os x os version x arch x compiler |
| 21:12:00 | Araq | well he can suggest that, but it's not gonna happen |
| 21:12:01 | gokr1 | CentOS 6.4 is not the same as Ubuntu 14.04 LTS, so to speak. |
| 21:12:11 | Araq | for me it is |
| 21:12:16 | gokr1 | I am not suggesting anything. I am asking. |
| 21:12:39 | flaviu | sorry, my bad |
| 21:12:56 | Araq | we also don't test windows 7 vs 7 vs vista vs xp |
| 21:13:30 | Araq | or AMD vs Intel CPUs |
| 21:13:58 | Araq | we know the dependencies and picked a reasonable test vector |
| 21:15:00 | Araq | you can't do anything else, the combinatorial explosion kills you quickly |
| 21:15:46 | flaviu | windows 7 vs xp might be reasonable though, if your target is to support winxp too. |
| 21:16:56 | gokr1 | So... I can revive our build server - it would run Ubuntu LTS, 64 bit. |
| 21:17:05 | Varriount | Dispatch: Here's a link to my opengl tutorial stuff: https://drive.google.com/file/d/0B077nrrf63xtQUJGYVdNdHhZcHc/view?usp=sharing |
| 21:17:39 | gokr1 | And it could build more (x86, BSD) via vagrant I presume. |
| 21:18:21 | Jehan_ | Araq: What should the lock level of a method dispatcher be if different methods have different lock levels? |
| 21:18:26 | Jehan_ | max or min? |
| 21:19:18 | Varriount | gokr1: I don't mind hosting the Windows build bots. I don't know what to do for Mac OSX though. |
| 21:19:51 | gokr1 | I only have one MBP, and well, its not always sitting on the desktop doing nothing :) |
| 21:19:53 | flaviu | I'm not sure that you can virtualize x86 from a 64 bit host |
| 21:19:56 | Jehan_ | Right now, as far as I can tell, the lock level is just copied from a random method. |
| 21:20:03 | Varriount | flaviu: Uh, yes you can. |
| 21:20:19 | gokr1 | Yeah, no problem. |
| 21:20:48 | flaviu | ok, that sounds good. Makes sense I guess, x64 cpus also support x86 |
| 21:20:56 | Varriount | gokr1: As for the version of gcc, I really only had 'the latest stable version' in mind. |
| 21:21:26 | Varriount | Actually, I'm more concerned about compilers themselves, rather than versions. |
| 21:21:30 | gokr1 | I just checked for fun - on my laptop Ubuntu 14.04 LTS gcc is 4.8.2. |
| 21:21:55 | Varriount | We don't test if things build on clang or vcc, for example. |
| 21:22:00 | Araq | Jehan_: well there is surely a bug here |
| 21:22:22 | Araq | but the dispatcher is what counts |
| 21:22:30 | hopla | I am playing with emit pragma and I got a _mm_load_ps working :-). Is there any way to enforce alignment of arrays (or other structures)? |
| 21:22:32 | Araq | or rather the base method |
| 21:23:09 | Jehan_ | Hmm. |
| 21:23:18 | Araq | hopla: not really, but seq[0] is 16 byte aligned I think |
| 21:23:19 | Jehan_ | As I said, rabbit hole. :) |
| 21:23:34 | Matthias247 | grrr @ gcc4.8.2 That shitty thing fails on my library :( |
| 21:23:49 | Varriount | Matthias247: Which library? |
| 21:23:51 | hopla | Araq: or is there a way to "import" a ctype (like __m128)? |
| 21:23:56 | Dispatch | @Varriount thx for the texture loading pointer, works like a charm |
| 21:24:03 | Matthias247 | Varriount: my @work stuff |
| 21:24:41 | Jehan_ | Base method would be the least specific method if there's one? |
| 21:24:44 | Matthias247 | Varriount: runs on windows and with gcc4.9, but 4.8.2 crashes |
| 21:24:50 | Araq | Jehan_: yes |
| 21:25:48 | Araq | as for the lock level direction, I don't know. I always get <= and >= wrong, so I write a test case and pick what works |
| 21:26:28 | gokr1 | Varriount: I can set up a slave tomorrow, my email is [email protected] - if you have some ... specific info to me. |
| 21:26:28 | Jehan_ | Araq: Here's the thing, there may not be a least specific method. |
| 21:26:38 | Varriount | gokr1: Optimally, we would have enough resources to do one build target per platform per architecture per compiler, possibly using the last two or three major versions of the compiler. |
| 21:26:53 | Jehan_ | E.g.: T2 <: T1, f(T1, T2), f(T2, T1), f(T2, T2). |
| 21:27:21 | Araq | he he, yeah |
| 21:27:24 | Jehan_ | So my current idea would be to pick either the min or the max of all method lock levels. |
| 21:28:05 | Jehan_ | If it's max, then the dispatcher has to be called from only code that exceeds ALL the lock levels of all the methods. |
| 21:28:22 | Jehan_ | if It's min, then having different branches with different lock levels is a warning (and later an error). |
| 21:28:26 | Varriount | gokr1: However, in the grand scheme of things, having one build target per platform per architecture is... acceptable (Although I really would like to test clang and vcc) |
| 21:28:29 | Araq | hopla: sure. via importc. only works for nominal types though. |
| 21:28:41 | hopla | Araq: I am going to hack a SIMD library with _mm_loadu_ps (unaliged loads) for now and use of emit all over the place. nim is really exciting. In particular, the template system. At least a C-like language that exposes the AST in a nice way. congratz to you all for the nice work! |
| 21:29:34 | Jehan_ | My gut feeling is to go for the max, but then the warning/error in sempass2 would never occur. |
| 21:29:38 | hopla | Araq: ah thanks! |
| 21:29:48 | Araq | hopla: usually importc suffices and is much nicer than emit |
| 21:30:17 | hopla | Araq: I am going to scan the compiler source to see how it works. Thank you! |
| 21:31:24 | Jehan_ | hopla: https://bitbucket.org/behrends/nimlongint/src/default/longint.nim |
| 21:32:35 | hopla | Jehan_: Oh yeah! |
| 21:33:33 | Jehan_ | Just so you know, {.emit.} is problematic; I used it to keep stuff in a single file. |
| 21:33:36 | hopla | I am more and more interested. Maybe nim can offer the syntax power to have a proper simd_if/simd_while... |
| 21:33:58 | Araq | hopla: start with reading the internal documentation if you wanna hack the compiler |
| 21:34:20 | Jehan_ | Let's just say that hacking the compiler (any compiler, really) is not for the faint of heart. |
| 21:34:24 | Araq | I think it's slim enough so that it's not really outdated |
| 21:35:03 | hopla | Araq: I was reading it. But I need nim mileage anyway now :-) I am going to implement a SIMD/vec library first. Need to do my home work. |
| 21:36:37 | * | q66[lap] quit (Read error: Connection reset by peer) |
| 21:37:06 | hopla | Araq: Once homework done, I should be able to investigate more :-) |
| 21:37:17 | * | q66[lap] joined #nimrod |
| 21:37:39 | Araq | Jehan_: another solution is to simply require the same locking level |
| 21:37:48 | Jehan_ | Araq: Yeah, that's what I said. |
| 21:38:12 | Jehan_ | Basically, I update dispatcher locklevel incrementally. |
| 21:38:20 | Araq | er no. |
| 21:38:27 | Jehan_ | Each time a new method gets added, I either pick the min or max. |
| 21:38:32 | Araq | you check they all have the same lock level |
| 21:38:38 | Jehan_ | Wait. |
| 21:38:49 | Araq | that's completely different from your proposal ;-) |
| 21:39:07 | Jehan_ | If I pick the min, then sempass2 will trigger a warnLockLevel, because at least one branch will have the wrong lock level. |
| 21:39:33 | Jehan_ | Assuming they're not all equal. |
| 21:40:01 | Araq | method base() = ... # ok, no lock level |
| 21:40:47 | Araq | method base() {.locks: 1.} = # more specific, but declaration of lock level differs from the 1st base --> error |
| 21:41:14 | Araq | hrm a bit hard to explain since they all have the same name |
| 21:42:41 | Araq | but we can always check that the methods that fall into the same buck have all the same lock level |
| 21:42:51 | Jehan_ | Here's the thing. There's already a check in sempass2.nim that does exactly that. |
| 21:43:17 | Jehan_ | in CheckMethodEffects() |
| 21:43:31 | * | Dispatch quit (Ping timeout: 246 seconds) |
| 21:43:39 | Araq | well i know |
| 21:43:43 | Araq | but that does: branch.typ.lockLevel > disp.typ.lockLevel |
| 21:43:54 | Araq | not: branch.typ.lockLevel != disp.typ.lockLevel |
| 21:44:47 | Jehan_ | If I set disp.typ.lockLevel to min(branch.typ.lockLevel), it'll trigger because then at least one branch will have a higher lock level. |
| 21:46:00 | Jehan_ | If I set it to max, it'll never trigger, but require that callers have lock levels at least as high as the method branch with the highest lock level. |
| 21:46:53 | Araq | well you can't aggregate lock levels this way. |
| 21:47:14 | Jehan_ | Why not? |
| 21:47:33 | Jehan_ | They form a totally ordered set. |
| 21:47:47 | Araq | code may have already been sempass2'checked |
| 21:48:15 | Araq | and later you say, oh ok, method X really has lock level Y instead |
| 21:48:22 | Jehan_ | Ugh. |
| 21:49:01 | Jehan_ | Okay, then here's another problem. method prototypes currently are initialized with UnspecifiedLockLevel. |
| 21:49:39 | Jehan_ | But I think I can put the warning in there. |
| 21:49:47 | Araq | well |
| 21:50:17 | Jehan_ | Actually, may not, don't have type info available. I think. |
| 21:50:26 | Araq | my idea was: method m(x: Base) {.locks. 4.} |
| 21:50:37 | Araq | and then every 'm' is checked against that one |
| 21:50:48 | Araq | and whenever 'm' is called, lock level 4 is assumed |
| 21:51:52 | gokr1 | Idiotic question: If I have a Nim .so library (works fine) and call a proc with a cstring as arg (works fine) - if I want to turn it into a Nim string - I just do "$myCstring", right? |
| 21:51:55 | Jehan_ | So, the first method to be specified gets to define the lock level? |
| 21:52:11 | Araq | gokr1: yes |
| 21:52:12 | Jehan_ | gokr1: Yes. |
| 21:52:22 | Araq | Jehan_: exactly |
| 21:52:31 | * | gokr1 hrmph.... why, why, why... does it blow up.... |
| 21:52:58 | Jehan_ | What if there are multiple modules that define methods with the same name? After all, that's one of the main reasons to use them over variant types. |
| 21:55:50 | flaviu | Araq: Can you clarify what was wrong with https://github.com/Araq/Nimrod/pull/1618? Doesn't newString automatically add a trailing null? |
| 21:55:54 | Araq | gokr1: built with libnimrlt.so? |
| 21:56:12 | gokr1 | Hummmm, ah, so perhaps I missed that... |
| 21:56:56 | Araq | Jehan_: yes. that's the real problem, I think |
| 21:57:28 | Araq | and maybe we finally need to acknoledge that some special .dispatcher method header needs to be introduced |
| 21:57:55 | Jehan_ | Araq: I think at the moment I'll be going with just raising a warning if lock levels differ. |
| 21:58:09 | Araq | which every concrete method then is bound to |
| 21:58:22 | Araq | arguably that's also cleaner than what we have now |
| 21:58:46 | Araq | where there is this mythical dispatcher method that can't be named |
| 21:58:58 | * | Trustable quit (Quit: Leaving) |
| 21:59:30 | Araq | flaviu: it does, and you're right that it should be 24, not 25 |
| 21:59:45 | Araq | but you also changed the semantics of that cstring proc |
| 21:59:52 | Araq | which is exported |
| 22:00:18 | flaviu | Oh, I didn't notice that it was a cstring |
| 22:01:01 | flaviu | setLen would be acceptable then? |
| 22:01:32 | Araq | no, just fix the 25. then it's fine |
| 22:02:19 | Araq | Jehan_: well ok, but that's what the code already does, right? |
| 22:02:44 | Jehan_ | Araq: Actually, no. |
| 22:03:00 | Jehan_ | Because method prototypes have an unspecified lock level. |
| 22:03:14 | Jehan_ | I.e. -1 |
| 22:03:44 | Jehan_ | Plus, currently the code picks basically a random branch. |
| 22:04:10 | Jehan_ | I ran into it because I tidied up dispatcher creation to always base it upon the first method instance encountered. |
| 22:04:24 | Jehan_ | Which happened to be a method prototype in my testcase. |
| 22:07:32 | * | hopla quit (Quit: Page closed) |
| 22:13:34 | Araq | pfff |
| 22:13:52 | Jehan_ | Hmm, another problem is that I've based my branch on devel, but the lockLevel stuff only works for bigbreak. |
| 22:14:06 | Jehan_ | when defined(NimVersion)? |
| 22:14:49 | Araq | well I want to merge devel into master and bigbreak into devel ... |
| 22:15:00 | Jehan_ | Eh, declared |
| 22:18:04 | Jehan_ | Well, I can right now do one of two things: Submit changes for devel with the stuff that works only for bigbreak behind a when declared(NimVersion) or submit changes for bigbreak instead. |
| 22:19:22 | Jehan_ | Or I can submit the changes for devel without the lock level stuff, but then a separate patch will have to be applied after a merge into bigbreak, which can't go through the normal PR interface. |
| 22:19:58 | Jehan_ | Actually, when declared(TLockLevel) is probably cleaner. |
| 22:20:57 | Jehan_ | Yeah, I'll do that. If necessary, we can still tidy all of this up. |
| 22:21:37 | Jehan_ | Let's first get the code out for review. |
| 22:27:24 | Araq | ok, I don't care about the branch really. |
| 22:27:55 | Araq | but I think all the other effect stuff has the same problems wrt methods |
| 22:28:16 | Araq | so I really think we need something like .dispatcher |
| 22:28:34 | gokr1 | Araq: If I compile my lib with -d:useNimRtl - should ldd on my lib list libnimrtl.so ? |
| 22:31:28 | Jehan_ | Araq: I'm putting it out for devel because lots of people currently still use devel and so I think having all the method dispatch stuff fixed there is a good idea. |
| 22:32:01 | Araq | gokr1: no. ldd doesn't detect dlsym usages |
| 22:32:34 | gokr1 | Right, I just noticed ... running it with a main - worked if I put the libnimrtl.so in /lib/blabla |
| 22:36:32 | Jehan_ | Araq: Okay, updated PR. |
| 22:37:48 | gokr1 | Hmmm, I think I will give up on this for the moment. Compiling with the rtl - then nothing works suddenly :) |
| 22:38:07 | Jehan_ | gokr1: By default, Nim uses dlopen() to access dynamic libraries. |
| 22:38:10 | gokr1 | Every call, even hello that returns 42 - segfaults. |
| 22:38:19 | Jehan_ | You can change that with --dynliboverride |
| 22:39:15 | gokr1 | I am not even sure ... using Nim like this is interesting for us, given the limitations of Nim in an .so. |
| 22:39:53 | gokr1 | (I am playing with ffi calls from Squeak to a .so lib written in Nim) |
| 22:47:04 | NimBot | Araq/Nimrod devel 72f4620 Varriount [+0 ±1 -0]: Update nsis.tmpl |
| 22:51:28 | Varriount | Araq: How do you feel about adding csources\* to gitignore? |
| 22:52:12 | Araq | fine with me for the nim repo |
| 22:52:54 | Varriount | Ok, thanks. |
| 22:53:20 | * | irrequietus quit () |
| 23:11:22 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:28:10 | Varriount | Araq: Here's the fixed installers. I verified that they install the correct shortcuts to the start menu, and that the compilers in them can compile koch.nim. |
| 23:28:14 | Varriount | https://drive.google.com/file/d/0B077nrrf63xtaXhIUk9mTXBkMkE/view?usp=sharing |
| 23:29:07 | gokr1 | I can report that I needed two things: build libnimrtl.so in 32 bits, and put it in a nice path. And drop my erroneous --noMain from the cfg, that made it blow up :) |
| 23:30:10 | Araq | Varriount: how did you fix it? |
| 23:30:53 | * | brson quit (Ping timeout: 240 seconds) |
| 23:32:26 | NimBot | Araq/Nimrod devel be0fbde Varriount [+0 ±1 -0]: Update nsis.tmpl |
| 23:32:43 | Varriount | Araq: See the change diff for that commit |
| 23:33:34 | Araq | ok, I don't get it, but it's lat |
| 23:33:36 | Araq | *late |
| 23:34:12 | Varriount | Araq: The startmenu macros have to surround calls to createshortcut |
| 23:34:46 | Araq | ah ok |
| 23:34:55 | Araq | well I have some patches for this too |
| 23:35:13 | Araq | but whatever, you tested it, let's ship that |
| 23:36:41 | Varriount | Araq: If you need to patch it, go ahead. |
| 23:37:18 | Varriount | It doesn't take a lot of work to generate the installers - I already have the repo's set up and everything. |
| 23:38:17 | Araq | ok, wait a sec then |
| 23:38:31 | Varriount | Well, rather, the downloads - I've been using the 9.6.0 release tag on github to download the Nimrod source to use in the installer, and have been updating nsis.tmpl manually. |
| 23:40:46 | * | Jehan_ quit (Quit: Leaving) |
| 23:46:26 | NimBot | nimrod-code/csources master e2f9238 Araq [+0 ±2 -0]: fixes the build for windows |
| 23:46:41 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 23:47:39 | * | johnsoft joined #nimrod |
| 23:49:24 | Araq | Varriount: that was the problem you meant, right? |
| 23:52:25 | Varriount | Yes. |
| 23:53:06 | Varriount | Araq: Do you have patches related to the installer/developer release? |
| 23:54:06 | Araq | yes, one sec |
| 23:57:48 | NimBot | Araq/Nimrod devel 621ead4 Araq [+0 ±2 -0]: only produce the link to the docs if they are installed |
| 23:57:55 | Araq | Varriount: here you go |
| 23:59:31 | Araq | btw niminst should be its own github repository |