| 00:11:37 | * | zahary quit (Read error: Connection reset by peer) |
| 00:16:38 | * | zahary joined #nimrod |
| 00:18:21 | * | Trixar_za is now known as Trix[a]r_za |
| 01:52:21 | * | zahary quit (Read error: Connection reset by peer) |
| 01:54:21 | * | zahary joined #nimrod |
| 02:06:32 | * | zahary quit (Quit: Leaving.) |
| 02:46:41 | * | SchalaZeal joined #nimrod |
| 02:47:19 | SchalaZeal | How would I go about making a tuple whose fields span more than 1 line, for readability? |
| 02:53:59 | fowl | separate the fields with , |
| 02:54:18 | SchalaZeal | hmm... well I'll try again |
| 02:54:49 | fowl | http://pastebin.com/5P3pTn0s |
| 02:54:58 | fowl | that worked fine in interactive mode |
| 02:55:41 | SchalaZeal | oops I forgot the brackets |
| 03:00:22 | SchalaZeal | I always wondered why {.pure, final.} objects are used instead of {.pure.} tuples for C wrappers. C structs are like tuples in that they share the sequential order factor (ie. struct Person fred = {"Fred", 29}; and TPerson fred = ("Fred", 29)) |
| 03:00:37 | SchalaZeal | makes more sense I'd think |
| 05:11:10 | Araq | SchalaZeal: the reason is that C's structs use nominal typing |
| 05:11:19 | Araq | so we use a nominal type in nimrod as well |
| 05:11:36 | Araq | plus when most of the wrappers were created tuples weren't up for the task ... |
| 05:11:40 | Araq | see you later |
| 05:26:49 | SchalaZeal | ah ok |
| 05:28:19 | SchalaZeal | for format() in times, I'm trying to find a separator token to use so "sszzz" won't be an invalid format but instead like... "59+08:00" (seconds, tz offset) |
| 05:29:52 | SchalaZeal | specifically I'm trying to make a proc that takes a TTime as a parameter and returns it as an ISO8601 date-time strong |
| 05:30:28 | SchalaZeal | like 2012-07-12T22:30:54+08:00 |
| 05:30:34 | SchalaZeal | string** |
| 05:31:57 | SchalaZeal | "yyyy'-'MM'-'dd'T'HH':'mm':'sszzz" does not seem to work |
| 05:32:13 | SchalaZeal | because of the sszzz part |
| 05:55:11 | SchalaZeal | err... guess not... adding '' helps |
| 05:55:13 | SchalaZeal | heh |
| 05:59:11 | SchalaZeal | hmm.. +/- in the offset won't show |
| 06:05:43 | SchalaZeal | is it a bug or am I flubbing up? |
| 06:14:33 | * | fowl quit (Quit: Leaving) |
| 06:17:34 | * | fowl joined #nimrod |
| 07:39:49 | SchalaZeal | ugh..... making a binding to one function in libeay32.dll is frustrating |
| 08:07:56 | * | zahary joined #nimrod |
| 08:39:32 | * | Trix[a]r_za is now known as Trixar_za |
| 08:45:35 | fowl | omg |
| 08:45:40 | fowl | parsing json this way is messy |
| 08:46:15 | fowl | i long for ruby's JSON.parse() |
| 08:47:27 | SchalaZeal | I'm having a tough time figuring out how to generate a SHA1 digest |
| 08:48:53 | fowl | hmm i only saw md5 and base64 stuff |
| 08:49:27 | SchalaZeal | Well the protocol I'm implementing calls to use SHA1 for passwords |
| 09:07:27 | * | SchalaZeal quit () |
| 10:26:48 | dom96 | hello. |
| 10:29:07 | dom96 | ARMs test results are the same as x86 test results. That's quite good. |
| 11:01:21 | dom96 | fowl: Why do you think parsing JSON in Nimrod is messy? |
| 11:42:09 | * | XAMPP[0] joined #nimrod |
| 11:45:15 | * | XAMPP quit (Read error: Connection reset by peer) |
| 12:01:28 | * | Trixar_za is now known as Trix[a]r_za |
| 12:42:13 | fowl | dom96, the way i have to do it is messy, checking if every field is there before i use it |
| 12:42:54 | dom96 | fowl: You don't have to check. |
| 12:43:36 | fowl | i have to check if an object exists and is an object before i attempt to index it, then make sure the index is there |
| 12:45:33 | dom96 | No you don't: https://gist.github.com/a3272bad33db21602937 |
| 12:46:06 | dom96 | Only scenario where you would check in is if the structure of the JSON cannot be guaranteed. |
| 12:46:16 | fowl | dom96, you know that everything is there, i'm expecting sections/values to be missing |
| 12:46:53 | dom96 | well then it's not wonder you need to check, how does Ruby get around this? |
| 12:47:00 | dom96 | Don't you have to perform checks there too? |
| 12:52:28 | * | fowl quit (Ping timeout: 246 seconds) |
| 13:16:55 | * | Araq_ joined #nimrod |
| 13:26:36 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901]) |
| 13:26:55 | * | Araq_ joined #nimrod |
| 13:28:15 | * | fowl joined #nimrod |
| 13:28:15 | * | fowl quit (Changing host) |
| 13:28:15 | * | fowl joined #nimrod |
| 13:29:53 | dom96 | <dom96> well then it's not wonder you need to check, how does Ruby get around this? |
| 13:29:53 | dom96 | <dom96> Don't you have to perform checks there too? |
| 13:30:02 | dom96 | fowl: ^^ |
| 13:31:23 | fowl | ah |
| 13:34:25 | fowl | its a lot more forgiving in ruby, parsing it gives u a hash then you can just use `hash["key"] or defaultValue` because missing key defaults to nil |
| 13:35:02 | dom96 | You could probably write a nice proc that does that for you. |
| 13:36:15 | fowl | this is what i came up with https://gist.github.com/3098147 |
| 13:40:10 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901]) |
| 13:42:58 | dom96 | I can't cope up with anything better heh |
| 13:46:14 | fowl | when nim compiles to c there is a lot of backtracing stuff like F.line = 70;F.filename = "tables.nim"; doesnt that slow down the program |
| 13:53:32 | dom96 | That's only in debug mode. |
| 13:53:41 | dom96 | It disappears when you compile with -d:release |
| 13:53:45 | fowl | ah |
| 13:54:04 | fowl | that makes sense :D |
| 14:00:48 | dom96 | :) |
| 14:39:47 | * | Trix[a]r_za is now known as Trixar_za |
| 15:29:40 | dom96 | Araq: Should type conversion of PTreeModel to PListStore be possible? |
| 15:58:35 | * | SchalaZeal joined #nimrod |
| 15:59:57 | SchalaZeal | does Nimrod or any of its wrappers have SHA1 support? |
| 16:01:11 | Araq | SchalaZeal: I dunno about the wrappers, there is no native nimrod implementation |
| 16:01:32 | Araq | openssl wrapper may provide it? I dunno |
| 16:02:57 | SchalaZeal | It does but the wrapper isn't comprehensive, and I had a memory error when trying to make a binding for SHA1() |
| 16:03:48 | SchalaZeal | SHA1() is declared in openssl/sha1.h as taking unsigned char*s and what not |
| 16:04:57 | Araq | what's so hard about 'cstring'? it is compatible to "unsigned char*" ... |
| 16:05:11 | SchalaZeal | oh? |
| 16:05:27 | Araq | what's so hard to grasp that "unsigned" has almost no effect when wrapping a DLL? |
| 16:05:47 | SchalaZeal | didn't know that... here I was making a cuchar datatype with importc unsigned char |
| 16:05:49 | Araq | and "volatile const" too btw ... |
| 16:06:27 | SchalaZeal | well I learned something new today--though what do you mean by almost? |
| 16:07:21 | Araq | mySignedCInt = c_proc_that_takes_unsigned() |
| 16:07:38 | Araq | # --> mySignedCInt contains a negative number for large unsigned numbers |
| 16:07:57 | SchalaZeal | so... not really relevant? |
| 16:08:04 | Araq | yes |
| 16:08:25 | SchalaZeal | yes as in it isn't or is? |
| 16:08:33 | Araq | yes it isn't :-) |
| 16:08:38 | SchalaZeal | Sorry if this is unnerving |
| 16:08:41 | SchalaZeal | lol ok |
| 16:09:15 | * | SchalaZeal has to update her own wrappers now. |
| 16:09:41 | SchalaZeal | I is not very attentivez |
| 16:11:58 | SchalaZeal | Sometimes implementing backwards compatibility is a pain |
| 16:12:56 | dom96 | Araq: Should type conversion of PTreeModel to PListStore be possible? |
| 16:13:07 | dom96 | (read the logs damn it :P) |
| 16:13:09 | Araq | no idea what you're talking about, dom96 |
| 16:13:28 | dom96 | Well, I used type names because it's a bit hard to explain I guess. |
| 16:13:36 | dom96 | PListStore inherits from PTreeModel |
| 16:13:50 | SchalaZeal | ooh! I think I got SHA1() to work! |
| 16:14:43 | SchalaZeal | proc sha1*(d: cstring, n: int, md: cstring): cstring{.cdecl, importc: "SHA1", dynlib: libeay32.} manages to print out gibberish when I pass it to echo with cstring parameters |
| 16:15:22 | SchalaZeal | said parameters, of course, being something readable |
| 16:17:34 | Araq | dom96: context? |
| 16:21:10 | dom96 | var ls = cast[PListStore](win.errorListWidget.getModel()) |
| 16:21:13 | dom96 | ls.append(...) |
| 16:28:29 | SchalaZeal | In the times module, when using format() I can't get the positive/negative character to show up in timezone offset |
| 16:29:07 | SchalaZeal | http://pastebin.com/bnskE2Yd |
| 16:29:18 | SchalaZeal | that's how I'm currently doing it |
| 16:33:53 | SchalaZeal | Was wondering if it's a bug or my own slip up |
| 16:33:55 | Araq | dom96: dont cast |
| 16:34:13 | dom96 | Araq: What do I do instead then? |
| 16:35:32 | * | Trixar_za is now known as Trix[a]r_za |
| 16:39:07 | Araq | PListStore(...getModel()) ? |
| 16:39:35 | Araq | and if that isn't allowed it's a bug in the wrapper or you're trying wrong things |
| 16:39:39 | dom96 | That doesn't work. |
| 16:40:02 | Araq | links to the gtk docs please |
| 16:41:26 | dom96 | http://developer.gnome.org/gtk/2.24/GtkListStore.html |
| 16:47:15 | Araq | it says GtkListStore "implements" GtkTreeModel |
| 16:47:34 | Araq | I dunno what that means for binary compatibility in Gtk ... |
| 16:47:49 | Araq | perhaps the 'cast' is valid and necessary ... |
| 16:57:20 | SchalaZeal | How would I get the plus/minus sign to appear on a formatted date? formatting 'zzz' doesn't work |
| 16:57:48 | Araq | dunno, dom96? |
| 16:58:07 | SchalaZeal | he wrote format()? |
| 16:58:22 | dom96 | yeah, I wrote it. |
| 16:58:57 | dom96 | 'zzz' should give the plus/minus |
| 16:59:00 | dom96 | I guess that's a bug |
| 16:59:04 | SchalaZeal | Ah, well when I specify 'zzz' in format, it would print 08:00 as opposed to -08:00 or +08:00 |
| 16:59:10 | SchalaZeal | Ah okay |
| 17:01:21 | SchalaZeal | I'm a little confused when and when not to use incompleteStruct pragma in my wrappers. I've seen other wrappers declare {.pure, final.} objects of structs that have the fields hidden |
| 17:02:04 | dom96 | I'll fix it for you. Just give me a couple of minutes :) |
| 17:02:28 | SchalaZeal | awesome |
| 17:02:55 | SchalaZeal | anyway, I thought incompleteStruct was for such a purpose but... am I wrong? |
| 17:03:41 | dom96 | I don't think so. I'm not really sure. |
| 17:04:23 | SchalaZeal | hmm |
| 17:06:00 | SchalaZeal | and when I'm making a const for a lib name to use for dynlib pragma, do the parentheses only work for .so/.dylib, or can it be used for DLLs too? |
| 17:06:46 | Araq | incompleteStruct is only ever necessary with 'header' |
| 17:06:48 | Araq | if you don't import via a header, you don't need it |
| 17:06:53 | Araq | and it will only do harm |
| 17:06:55 | Araq | the () work for DLLs too of course |
| 17:07:05 | Araq | gonna fix these connection problems, see you later |
| 17:07:38 | SchalaZeal | ah ok |
| 17:08:17 | dom96 | gah, my offset is 00:00 |
| 17:08:28 | dom96 | So that doesn't help :P |
| 17:12:55 | dom96 | SchalaZeal: Any ideas how to change timezone temporarily? |
| 17:23:55 | SchalaZeal | uhm |
| 17:24:03 | SchalaZeal | hmm |
| 17:24:12 | SchalaZeal | let me check docs |
| 17:24:47 | SchalaZeal | TTimeInfo.timezone or tzname? |
| 17:24:54 | SchalaZeal | modify those? |
| 17:25:15 | SchalaZeal | btw, my offset was 00:00 as well |
| 17:26:02 | SchalaZeal | prefs test |
| 17:26:06 | dom96 | well maybe it prints the minus and plus when the offset is actually something? |
| 17:26:07 | SchalaZeal | oh there we go |
| 17:26:21 | SchalaZeal | yeah that's my guess |
| 17:26:33 | SchalaZeal | thing is it isn't being detected |
| 17:27:03 | SchalaZeal | timezone that is |
| 17:28:40 | dom96 | how so? |
| 17:29:45 | SchalaZeal | well... it was 00:00 for me too |
| 17:29:56 | SchalaZeal | and I believe I am GMT 08:00 |
| 17:30:05 | SchalaZeal | or... whatever Pacific US time is |
| 17:30:27 | dom96 | oh |
| 17:44:22 | dom96 | Well, I just set the timezone to Asia/Kolkata and it says -05:00 |
| 17:48:52 | dom96 | Not sure why it says that Berlin is -1 |
| 17:48:57 | dom96 | Should be +1 |
| 17:49:01 | SchalaZeal | odd |
| 17:49:09 | dom96 | Well actually +2 currently I think |
| 17:49:17 | SchalaZeal | well at least you made progress |
| 17:50:05 | dom96 | date +%z |
| 17:50:09 | dom96 | gives the right thing hrm |
| 17:50:53 | SchalaZeal | hm |
| 17:51:14 | dom96 | timezone = -3600 |
| 17:51:23 | dom96 | So I'm really puzzled |
| 17:51:39 | dom96 | hrm. |
| 17:51:57 | dom96 | However that's non-dst so... it's correct I think |
| 17:52:03 | dom96 | except for the minus |
| 17:54:27 | dom96 | It's the offset west of UTC |
| 17:54:30 | dom96 | so hrm |
| 17:54:41 | dom96 | Maybe I should just negate it |
| 17:56:28 | SchalaZeal | possibly |
| 17:56:51 | Araq | but if C does it that way, maybe there is a reason for it? |
| 17:57:19 | Araq | dates are hard to get right |
| 17:57:25 | Araq | please look up this stuff ... |
| 17:57:54 | Araq | don't just hack around until you get what you think is a "correct" result ... |
| 17:58:35 | dom96 | Hey, I did look it up. |
| 17:59:59 | Araq | ok then |
| 18:01:11 | dom96 | Apparently I didn't look it up well enough |
| 18:03:56 | Araq | what ocaml's strings are mutable? |
| 18:04:37 | dom96 | "difference from UTC and local standard time" |
| 18:04:39 | dom96 | hrm |
| 18:05:08 | SchalaZeal | If a numeric value isn't specified for an enum value, is it 0? |
| 18:06:32 | SchalaZeal | Trying to port over an unnamed enum but it has no numeric values |
| 18:08:39 | Araq | it starts from 0 then, yes |
| 18:09:44 | SchalaZeal | okay |
| 18:11:02 | Araq | any reason why you don't c2nim it? |
| 18:11:30 | SchalaZeal | because it gets messy |
| 18:11:58 | SchalaZeal | and also apparently this developer felt the need to have an unordered enum |
| 18:12:33 | SchalaZeal | like enum MyEnum { A = 9, B = 5, C = 6 }; ..... easy fix but man that's annoying |
| 18:13:51 | Araq | I always use c2nim and then fix the nimrod code :-) |
| 18:14:07 | Araq | well I also fix the C code to compile with c2nim ... |
| 18:14:15 | Araq | but it saves lots of tedious typing |
| 18:14:44 | SchalaZeal | heh |
| 18:15:25 | SchalaZeal | I'm looking c2nim over... uhm... what's --dynlib mean? That I can pass in a DLL input, or that it points the procs to import from a DLL? |
| 18:17:18 | Araq | the later |
| 18:19:16 | dom96 | Well I'm really puzzled by this timezone stuff. |
| 18:20:10 | SchalaZeal | hmm... c2nim chokes on a function pointer typedef |
| 18:20:21 | Araq | who doesn't? |
| 18:20:23 | Araq | :D |
| 18:20:33 | Araq | function pointer syntax is a pita in C ... |
| 18:20:57 | SchalaZeal | comment it out, type it myself later? |
| 18:21:13 | Araq | yep |
| 18:21:30 | Araq | that's the spirit of c2nim :D |
| 18:26:32 | SchalaZeal | heh... solved most of my problems finding and replacing "WINAPI" with nothing |
| 18:27:13 | SchalaZeal | hmm... but now I have another concern |
| 18:27:25 | SchalaZeal | if consts count as defines |
| 18:27:36 | SchalaZeal | because if not..........yeeeeeeeah.......... |
| 18:27:44 | Araq | er SchalaZeal |
| 18:27:52 | Araq | please learn to use c2nim ... |
| 18:28:01 | Araq | #def WINAPI |
| 18:28:11 | Araq | would do the replacement for you for example |
| 18:29:50 | SchalaZeal | okay... uhm... thing is when I converted the consts, it would be like "const Foo = true" and later "when defined(Foo)" |
| 18:30:58 | Araq | hrm |
| 18:37:10 | Araq | well translate that to: |
| 18:37:15 | Araq | const Foo = true |
| 18:37:17 | Araq | when Foo: |
| 18:37:29 | Araq | that's the most nimrodic way |
| 18:40:57 | SchalaZeal | ok |
| 18:49:03 | SchalaZeal | ugh..... one of the Microsoft compiler catering #ifdef statements caused all the code to indent and there's no dedent |
| 18:49:08 | SchalaZeal | feature* |
| 18:50:24 | Araq | determine what's defined |
| 18:50:32 | Araq | and get rid of the #ifdef |
| 18:50:36 | Araq | and then use c2nim |
| 18:50:57 | SchalaZeal | ok |
| 18:55:42 | SchalaZeal | there we go |
| 18:56:08 | SchalaZeal | comment out the header define guards, indent problem gone |
| 19:06:47 | SchalaZeal | hmm.... c2nim seems to translate unsigned primitives into stuff like cunsignedint, which doesn't exist |
| 19:08:33 | Araq | yeah well |
| 19:08:49 | Araq | I did it this way so no information is lost |
| 19:08:53 | Araq | you can easily do: |
| 19:08:55 | SchalaZeal | guess I find and replace stuff like cunsignedint -> cint? |
| 19:09:06 | Araq | yeah that's one way to do it |
| 19:09:09 | Araq | another is: |
| 19:09:14 | SchalaZeal | what's your way? |
| 19:09:38 | Araq | type cunsignedint = uint32 # now exists ;-) |
| 19:10:28 | SchalaZeal | yeah but aren't the signed C primitive types in the system module from C imports? |
| 19:11:08 | SchalaZeal | I mean I could do type cunsignedint{.importc: "unsigned int", nodecl.} = uint32 |
| 19:11:35 | SchalaZeal | I think |
| 19:11:46 | Araq | ugh, please don't |
| 19:11:53 | Araq | this feature is quite fragile ... |
| 19:12:07 | SchalaZeal | if you insist |
| 19:14:36 | SchalaZeal | ew.... http://pastebin.com/VBagpj1U |
| 19:15:17 | SchalaZeal | that..... is pretty ugly |
| 19:20:04 | Araq | cunsignedchar --> just use 'char' |
| 19:20:17 | Araq | and I would seriously use the dynlib approach |
| 19:20:26 | Araq | 'header' is ugly and much more fragile |
| 19:20:41 | Araq | as then I have to install the headers and import libs and stuff |
| 19:20:47 | Araq | just wrap the DLL please |
| 19:21:25 | SchalaZeal | yeah |
| 19:21:31 | SchalaZeal | thought so |
| 19:23:22 | * | Amrykid is now known as OdhE4DxgmF7Lb76W |
| 19:23:37 | * | OdhE4DxgmF7Lb76W is now known as Amrykid |
| 19:34:39 | SchalaZeal | alrighty, now to just fill in the part C2Nim choked on |
| 19:55:28 | SchalaZeal | done |
| 19:55:36 | SchalaZeal | lets write a test app |
| 20:00:15 | * | XAMPP[0] quit (Quit: There is no such thing as coincidence, only the inevitable.) |
| 20:04:20 | * | XAMPP joined #nimrod |
| 21:58:39 | SchalaZeal | and I failed |
| 22:00:37 | dom96 | what happened? D: |
| 22:01:09 | SchalaZeal | StormLib is too complicated to even test a wrapper on |
| 22:02:08 | SchalaZeal | It goes hand in hand with the ugly Win32 API |
| 22:02:15 | * | zahary quit (Quit: Leaving.) |
| 22:03:09 | dom96 | hehe |
| 22:03:20 | dom96 | What is StormLib? Some kind of a Diablo 1 extractor thing? |
| 22:04:21 | SchalaZeal | MPQ archive format |
| 22:04:32 | SchalaZeal | up to version 4 |
| 22:04:53 | Araq | cool |
| 22:05:13 | Araq | it seems to be quite easy to wrap according to the docs |
| 22:05:19 | Araq | what's the problem? |
| 22:05:31 | * | zahary joined #nimrod |
| 22:05:57 | SchalaZeal | It's too integrated with Win32 |
| 22:06:04 | SchalaZeal | Win32 has an ugly API |
| 22:06:48 | SchalaZeal | yes they have cross platform counterparts of what's needed but that doesn't make it look any more appealing |
| 22:08:44 | Araq | bool WINAPI SFileOpenArchive( |
| 22:08:46 | Araq | const char * szMpqName, // Archive file name |
| 22:08:48 | Araq | DWORD dwPriority, // Archive priority |
| 22:08:49 | Araq | DWORD dwFlags, // Open flags |
| 22:08:50 | Araq | HANDLE * phMPQ // Pointer to result HANDLE |
| 22:08:52 | Araq | ); |
| 22:08:54 | Araq | DWORD = int32 |
| 22:09:00 | Araq | HANDLE --> winlean.THandle |
| 22:09:08 | Araq | in fact |
| 22:09:12 | Araq | just import winlean |
| 22:31:12 | SchalaZeal | ah |
| 22:31:36 | SchalaZeal | well thing is I was hoping for a cross platform solution |
| 22:34:23 | SchalaZeal | Here's what I have so far |
| 22:34:25 | SchalaZeal | https://github.com/Schala/nimrod-modules/blob/master/lib/wrappers/storm.nim |
| 22:38:27 | Araq | that looks good |
| 22:38:31 | Araq | what's the problem? |
| 22:40:24 | SchalaZeal | tried rewriting the example file extract proc in Nimrod, kept messing up |
| 22:47:38 | Araq | hrm, but I have to sleep now |
| 22:47:41 | Araq | good night |
| 22:50:55 | SchalaZeal | k |
| 22:50:58 | SchalaZeal | night |
| 23:08:25 | * | XAMPP quit (Read error: Connection reset by peer) |
| 23:08:44 | * | XAMPP joined #nimrod |
| 23:08:45 | * | XAMPP quit (Changing host) |
| 23:08:45 | * | XAMPP joined #nimrod |