| 00:53:15 | * | BitPuffin quit (Ping timeout: 276 seconds) |
| 01:17:14 | * | Associat0r quit (Quit: Associat0r) |
| 02:07:41 | * | Trixar_zb is now known as Trixar_za |
| 02:14:15 | * | XAMPP joined #nimrod |
| 02:14:20 | * | q66 quit (Quit: Leaving) |
| 02:52:29 | * | XAMPP-8 joined #nimrod |
| 03:32:27 | * | OrionPK quit (Quit: Leaving) |
| 04:21:11 | * | XAMPP_8 joined #nimrod |
| 04:21:54 | * | XAMPP-8 quit (Ping timeout: 276 seconds) |
| 04:25:53 | * | XAMPP-8 joined #nimrod |
| 04:25:54 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
| 04:26:33 | * | XAMPP_8 quit (Ping timeout: 264 seconds) |
| 04:26:48 | * | Endeg joined #nimrod |
| 05:12:48 | * | darithorn joined #nimrod |
| 05:15:59 | * | XAMPP quit (Quit: Drink all the Booze; Hack all the Things; Kill all the Humans;) |
| 06:16:45 | * | XAMPP joined #nimrod |
| 06:16:45 | * | XAMPP quit (Changing host) |
| 06:16:45 | * | XAMPP joined #nimrod |
| 06:45:21 | darithorn | how do I use babel packages after installing them? |
| 06:47:44 | dom96 | Just import the module that the packages provide. |
| 06:47:52 | dom96 | For jester you would do: import jester |
| 06:47:58 | dom96 | After installing the babel package. |
| 06:48:10 | darithorn | When I do that it says it can't find jester |
| 06:48:24 | darithorn | I looked in ~/.babel/pkgs and jester is there |
| 06:48:35 | dom96 | Are you sure your nimrod config is right? |
| 06:48:47 | dom96 | does it have --babelPath:~/.babel/pkgs |
| 06:49:07 | dom96 | ? |
| 06:49:34 | dom96 | or something similar? |
| 06:49:59 | darithorn | Ah, it's pointing to $home/.babel/libs |
| 06:51:27 | dom96 | yeah, that's been changed recently. |
| 06:51:34 | dom96 | Just change it to pkgs |
| 06:52:54 | darithorn | alright, it seems to have worked. thanks |
| 06:53:08 | dom96 | np |
| 07:07:47 | * | Sergio965 joined #nimrod |
| 07:22:37 | * | Trixar_za is now known as Trix[a]r_za |
| 07:24:54 | * | Araq_ joined #nimrod |
| 07:46:06 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:53:52 | rndbit | goooood mooorning vietnaaaaammmm!!!! |
| 07:54:26 | * | Araq_ quit (Read error: Connection timed out) |
| 07:55:08 | * | Araq_ joined #nimrod |
| 08:00:15 | * | Associat0r joined #nimrod |
| 08:00:15 | * | Associat0r quit (Changing host) |
| 08:00:15 | * | Associat0r joined #nimrod |
| 08:45:53 | * | BitPuffin joined #nimrod |
| 09:01:56 | BitPuffin | I am not sure that genOID is all that good of a salt, the salts barely differ from each other. It probably doesn't matter because it still affects the output but they should be better! |
| 09:03:42 | Araq_ | BitPuffin: I think they are fine but I'm no expert in cryptography |
| 09:03:54 | Araq_ | rndbit: morning ;-) |
| 09:04:09 | BitPuffin | me neither, but I believe it is better for some reason if ther are completely random |
| 09:06:46 | BitPuffin | "The salts used in password hashes should be random" |
| 09:06:57 | BitPuffin | well they are not non-random |
| 09:06:58 | BitPuffin | but |
| 09:07:08 | BitPuffin | they are barely random |
| 09:11:01 | Araq_ | "barely" seems to be your perception only |
| 09:11:18 | Araq_ | it contains a random number generator part and a time stamp |
| 09:11:35 | Araq_ | and a counter that's always increased |
| 09:14:55 | * | EvilAww quit (Ping timeout: 264 seconds) |
| 09:16:47 | * | EXetoC joined #nimrod |
| 09:16:59 | BitPuffin | Araq_: well the only thing that differs from the salts is the last character pretty much |
| 09:17:43 | Araq_ | that's strange, maybe oids is buggy |
| 09:17:51 | BitPuffin | perhaps |
| 09:19:35 | BitPuffin | one salt: NTIwYzlkMDcxNTM2OGQxNjAwMDAwMDBj |
| 09:19:48 | BitPuffin | the salt before: NTIwYzlkMDcxNTM2OGQxNjAwMDAwMDBi |
| 09:20:08 | BitPuffin | the one before that: NTIwYzlkMDYxNTM2OGQxNjAwMDAwMDBh |
| 09:20:10 | BitPuffin | etc |
| 09:20:19 | BitPuffin | so it happens alphabetically |
| 09:20:25 | BitPuffin | pretty deterministic |
| 09:20:35 | Araq_ | yeah just like any good salt should be |
| 09:21:09 | BitPuffin | a good salt should be non-deterministic |
| 09:23:12 | Araq_ | I'm kidding |
| 09:23:17 | Araq_ | ok, found the bug ... -.- |
| 09:23:28 | Araq_ | oids.nim line 73 |
| 09:23:38 | Araq_ | dedent that line |
| 09:24:09 | Araq_ | and make a pull request |
| 09:37:42 | * | EvilAww joined #nimrod |
| 09:41:55 | * | q66 joined #nimrod |
| 09:49:59 | BitPuffin | Araq_: do I need to test it? |
| 09:50:14 | BitPuffin | because you know I can't bootstrap lol |
| 09:50:25 | Araq_ | no need to bootstrap |
| 09:50:38 | Araq_ | just edit the module and run your program again |
| 09:51:30 | BitPuffin | okay, just gonna find where it is |
| 09:56:13 | BitPuffin | Araq_: I am not sure it fixed it |
| 09:57:42 | BitPuffin | Araq_: I edited /usr/lib/nimrod/pure/oids.nim the way you said |
| 09:57:46 | BitPuffin | and this is the result |
| 09:58:53 | BitPuffin | salt1: NTIwY2E1OWExNDAzMzE1OTAwMDAwMDNj |
| 09:59:03 | BitPuffin | salt2: NTIwY2E1OWEyZjgwMmMzMjAwMDAwMDNk |
| 09:59:14 | BitPuffin | which is a bit more random at least |
| 09:59:17 | BitPuffin | or is it |
| 09:59:18 | BitPuffin | no |
| 09:59:20 | BitPuffin | it's the same |
| 10:00:16 | Araq_ | not it IS more random |
| 10:00:27 | Araq_ | however I'm not sure the "fix" is correct |
| 10:00:39 | Araq_ | I need to look it up in the original code |
| 10:01:52 | BitPuffin | yeah it seems slightly more random |
| 10:05:44 | Araq_ | well the old implementation seems to be correct |
| 10:06:17 | Araq_ | "fuzz" is a *machine* ID in the original implementation |
| 10:06:25 | BitPuffin | Araq_: could the fault lie in times or endians? |
| 10:06:29 | Araq_ | so it should stay constant |
| 10:07:00 | Araq_ | and this means you shouldn't use OIDs for salts |
| 10:07:26 | BitPuffin | hmm |
| 10:07:53 | BitPuffin | well maybe we should add ourselves a random string generator |
| 10:08:00 | Araq_ | yeah |
| 10:08:21 | BitPuffin | Araq_: I guess one weird way you could do it would be to hash the OID and base64 encode it |
| 10:08:41 | Araq_ | just use a random number generator |
| 10:08:47 | Araq_ | if you need random numbers |
| 10:09:09 | BitPuffin | yeah, just interpret the numbers as characters |
| 10:09:22 | BitPuffin | can't you use sets somehow? so you can say which characters are allowed? |
| 10:10:45 | Araq_ | just toHex(randomNumber and 0xff) a couple of times |
| 10:11:06 | Araq_ | to generate a random string |
| 10:16:14 | BitPuffin | why and 0xff? |
| 10:17:54 | Araq_ | well it's not really necessary |
| 10:18:03 | Araq_ | I forgot toHex's signature :P |
| 10:23:32 | BitPuffin | ah yes, what's that for? |
| 10:25:25 | Araq_ | to make it byte ranged |
| 10:30:30 | Araq_ | bbl |
| 10:30:44 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 11:39:53 | * | Araq_ joined #nimrod |
| 11:41:38 | dom96 | hello! |
| 12:04:06 | EXetoC | hi |
| 12:07:03 | * | Sergio965 joined #nimrod |
| 12:11:01 | * | Sergio965 quit (Read error: Operation timed out) |
| 12:27:17 | BitPuffin | hey EXetoC & dom96 |
| 12:57:34 | EXetoC | hello |
| 12:57:44 | dom96 | hi |
| 13:02:15 | * | Associat0r quit (Quit: Associat0r) |
| 13:03:19 | EXetoC | "a simple way of indexing the last element of an array or sequence, to avoid long-hand code like arr[arr.len-1]". I don't know if there should be a shorthand specifically for the last element, but it might not matter all that much, because that's usually the index that you want in that case, right? |
| 13:05:32 | EXetoC | also, a shortcut for x[y..y+z] would be nice, since that seems to be fairly common too, though both operations can be simplified by introducing additional variables |
| 13:08:10 | EXetoC | Like I said before, $ inside x[] in D is short for x.length, and so you often do x[$-1]. would adding a special case for some operator in this case be a bad idea? |
| 13:10:22 | Araq_ | it's a weird special case and doesn't fit the grammar at all |
| 13:10:39 | Araq_ | better introduce arr.lastElem |
| 13:11:36 | Araq_ | we already have arr[arr.high] btw, no need for the -1 |
| 13:12:13 | EXetoC | it's mostly an inconvenience when said identifier is long |
| 13:24:28 | EXetoC | "easier sorting, that doesn't need wrestling with types." I wonder if he's referring to the 'cmp' parameter, but the documentation is implying that it might change |
| 13:33:41 | * | Associat0r joined #nimrod |
| 13:33:41 | * | Associat0r quit (Changing host) |
| 13:33:41 | * | Associat0r joined #nimrod |
| 13:36:12 | EXetoC | I was going to say that this functionality "let x = sort(y.dup)" could be provided without introducing any overloads by tweaking 'var' a little and returning the original array, which would be elegant, but that's not going to work is it? since the sequence argument is an open array |
| 13:45:01 | Araq_ | it's a nice shortcut when you call 'sort' all the time |
| 13:45:11 | Araq_ | but who does that? |
| 13:47:59 | Araq_ | much more useful would be 'sorted' iterator |
| 13:48:13 | Araq_ | for x in sorted(myarray): echo x |
| 13:48:42 | EXetoC | I want shortcuts for most things really, but this is not necessarily about sort. I was thinking that maybe it would be possible to use a type class instead of openarray, when type class bugs are fixed anyway (in conjunction with type parameters etc) |
| 13:48:50 | EXetoC | yeah sure |
| 13:55:29 | Araq_ | and what would that type class look like? IsRandomAccessIterator? |
| 13:55:39 | * | fowl quit (Ping timeout: 240 seconds) |
| 13:56:26 | Araq_ | that's essentially what openarray already is, I don't care about hypothetical other ways to implement arrays on top of the "hardware supported arrays" |
| 13:56:59 | * | fowl joined #nimrod |
| 13:58:59 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 14:01:33 | EXetoC | well, can the return type be an open array? you might want the type to be that of a parameter |
| 14:19:40 | EXetoC | it'd be exactly the same thing other than that |
| 14:29:54 | EXetoC | what about functions that can mutate any kind of container? maybe if we define iterators that yields references, or would that be insufficient? |
| 15:02:46 | EXetoC | should work. you'd just have to call itemsRef or something |
| 15:11:03 | BitPuffin | EXetoC: in nimrod we would need a shorthand for the first and last element |
| 15:15:16 | EXetoC | when? |
| 15:15:32 | BitPuffin | EXetoC: well if we want something like $ from D |
| 15:16:04 | BitPuffin | EXetoC: then it would be useful to have a just as quick way to get the low. Because arrays in D always start at 0, not the case in nimrod |
| 15:17:56 | EXetoC | I still wouldn't need it that often for the first element I think, but ok |
| 15:19:43 | BitPuffin | EXetoC: well if you need to know the last elements index then you need to know the first elements index probably too. Let's say we one day got slicing in nimrod, we could do foobarray[&+3..$-1] |
| 15:30:13 | * | Trix[a]r_za is now known as Trixar_za |
| 15:54:18 | EXetoC | reference slices you mean? |
| 15:55:50 | EXetoC | we already have slices, but a slice on its own is just an object with two fields |
| 16:06:15 | EXetoC | were you not aware of that? considering what you said; because we already have [] and .. |
| 16:08:12 | BitPuffin | EXetoC: we have slices? |
| 16:09:44 | EXetoC | yes, but not like in D |
| 16:11:23 | EXetoC | look for "proc `..`" and "proc `[]`" in system.nim. it's pretty much just a library implementation |
| 16:28:11 | BitPuffin | hmm |
| 16:28:16 | BitPuffin | I'll have a look |
| 16:28:30 | BitPuffin | is there any XML-RPC utility for nimrod? |
| 16:44:58 | EXetoC | for i in ..x: "Error: type mismatch: got (TSlice[int])". this should work, right? it's a very limited shortcut otherwise |
| 16:57:02 | * | Mat2 joined #nimrod |
| 16:57:05 | Mat2 | hi @ all |
| 17:00:39 | EXetoC | hi |
| 17:00:56 | Mat2 | hi EXetoC |
| 17:01:32 | Mat2 | have you finished your vector library ? |
| 17:02:05 | EXetoC | I guess it's just that the compiler doesn't recognize the single-argument version in conjunction with 'for' |
| 17:02:36 | EXetoC | Mat2: I've never written a library intended for re-use. BitPuffin is however |
| 17:02:59 | Mat2 | ok, sorry - wrong remindment |
| 17:06:41 | EXetoC | not that making a vector lib re-usable is a difficult task :> |
| 17:08:32 | Mat2 | probably |
| 17:18:06 | rndbit | does anyone know what was rationale behind style of function argument type declarations? boo was first lang to bug me with types being defined after names, now nimrod.. why not just stick to mainstream way which by the way has one symbol less to type (no ':')? |
| 17:20:59 | EXetoC | good question. I often omit the type though |
| 17:21:45 | Mat2 | it's just behaviour, overcome simply |
| 17:22:44 | rndbit | im just wondering tho.. cause things like that seem as changes w/o a good reason. and changing something w/o reason isnt something smart |
| 17:23:00 | rndbit | besides it reminds me of pascal. any pascal haters here? raise your hands! |
| 17:23:02 | * | rndbit raises hand |
| 17:23:33 | Mat2 | I found Pascal a very well designed language in its extended versions |
| 17:24:04 | rndbit | very fugly-looking wrist-breaking |
| 17:24:35 | rndbit | assignment operator was probably what drove me nuts most |
| 17:24:49 | Mat2 | ... but lisp is naturally better in any aspect :D |
| 17:25:29 | rndbit | you know like those people that love hurting themselves? slice their arms and shit.. |
| 17:25:34 | rndbit | lisp is designed for them |
| 17:26:05 | Mat2 | *lol*, you don't know Lisp |
| 17:26:43 | rndbit | idk what that means. i saw lisp code, decided that i love myself too much and ran as far away as possible |
| 17:27:51 | Mat2 | seriously, it's all about taste |
| 17:28:34 | rndbit | guess so.. afterall there are people that eat soil |
| 17:35:56 | EXetoC | yum |
| 17:36:09 | Mat2 | no, I would say instead there are many tastes of equal valid preferences |
| 17:38:34 | rndbit | that statement may be valid for programming languages, but it definitely doesnt work in case of soil-eating people :| |
| 17:38:49 | EXetoC | taste is preference |
| 17:39:47 | Mat2 | taste doesn't matter, only algorithm does |
| 17:40:30 | Mat2 | ok, I need to finish a compiler |
| 17:40:37 | * | Mat2 Mat2-coding |
| 17:40:39 | * | gradha joined #nimrod |
| 17:41:43 | EXetoC | matter to whom? if you dislike a language, and you can use something else, you will :> and if you get paid then you might use it regardless |
| 17:41:58 | EXetoC | but I'm sure most people welcome reduced typing, but yeah it's not a big deal in this case |
| 17:42:10 | EXetoC | and Araq has been influenced by pascal |
| 17:42:19 | Mat2 | and oberon probably |
| 17:42:44 | EXetoC | and then there's the official pas2nim tool :> |
| 17:44:06 | gradha | nimrod is bad for commercial programs, you get paid by LOC, so nimrod looses a lot to other options |
| 17:44:45 | Mat2 | by the way: exist there a library for endian handling ? |
| 17:44:50 | Mat2 | hi gradha |
| 17:45:18 | gradha | I have epak in babel which implements serialization, if that's what you mean |
| 17:45:38 | EXetoC | and it might be easier to parse that way, and that's a priority I think |
| 17:45:38 | gradha | I'm rewriting it partially myself now for ouroboros |
| 17:45:56 | Mat2 | no I mean byte swapping depending on the endianess |
| 17:46:24 | dom96 | Mat2: There is an endians module. |
| 17:46:37 | Mat2 | hi dom96, thanks |
| 17:46:44 | dom96 | hi :) |
| 17:46:59 | Mat2 | hi gradha |
| 17:47:08 | gradha | hi Mat2 |
| 17:47:11 | gradha | hi Mat2 |
| 17:47:48 | EXetoC | grep -i -R . endian |
| 17:49:57 | rndbit | hmm i suppose nimrod could be flexible enough to allow me put types to where they are in c.. >:) |
| 17:50:04 | Araq | rndbit: the language that changed declaration syntax for no good reason is Golang |
| 17:50:25 | Araq | pretty much every language uses 'x: type' or 'type x' |
| 17:50:33 | Mat2 | hi Araq |
| 17:50:53 | * | Mat2 is now known as Mat2-coding |
| 17:51:01 | Araq | 'x: type' causes fewer ambiguities and allows for optional type annotations |
| 17:51:02 | rndbit | pretty much every? u mean pretty much every not that widely used lang ^_^ |
| 17:51:55 | Araq | "widely used" is not a criterion for quality |
| 17:52:18 | rndbit | not at first yeah.. |
| 17:52:28 | rndbit | but after 10-20 years i suppose it can be? |
| 17:52:40 | EXetoC | I don't think so |
| 17:53:09 | rndbit | do not people tend to use best tool available? |
| 17:53:13 | EXetoC | many languages are used because of industry support and what have you |
| 17:53:40 | rndbit | that makes sense yeah.. |
| 17:53:44 | gradha | rndbit: you can argue that between mobile platforms: java or objc? |
| 17:53:45 | Mat2-coding | rndbit: of course not |
| 17:54:14 | rndbit | gradha objc is... like c exposed to radiation :| |
| 17:54:27 | EXetoC | they do, but that might have to do with library support or availability of proficient programmers |
| 17:54:39 | gradha | rndbit: my point was, java had been used much more on mobile previous to the iphone, yet they used objc |
| 17:54:46 | gradha | years are rarely a factor |
| 17:55:20 | rndbit | ah but dont look at big corps, they make one choice and shove down developer's choices |
| 17:55:32 | rndbit | i had in mind more of solo developers who choose for themselves |
| 17:55:52 | Mat2-coding | rndbit: you can say, millions can't get wrong and bet: This is logical wrong |
| 17:56:40 | rndbit | more like millions try to use best tools available to them / suited for them |
| 17:57:13 | Mat2-coding | no, there use the tools which are familiar to them, taht does not implicite efficiency |
| 17:57:14 | gradha | rndbit: just yesterday I was talking with an android developer how much they welcome getting away from the horror that eclipse is, yet millions use that crap |
| 17:57:23 | Mat2-coding | ^that |
| 17:57:55 | rndbit | again - cause eclipse is shoved down their throat by google, just like objc is shoved down iOS dev's throat by apple |
| 17:58:12 | rndbit | it really is far from ideal, but its best tool available |
| 17:58:29 | gradha | rndbit: have you tried Aporia? |
| 17:58:42 | rndbit | yeah, im experimenting with it now |
| 17:59:48 | gradha | nihathrael was working on suggestion support in Aporia, it's going to be awesome |
| 18:00:30 | rndbit | what exactly that is? |
| 18:00:56 | gradha | it's context sensitive suggestion/completion for the editor, rather than string based |
| 18:01:12 | gradha | so you are typing a var, and it autocompletes the var properly |
| 18:01:14 | rndbit | ah, code completion thats called in my world |
| 18:01:16 | EXetoC | Mat2-coding: yeah, because management doesn't have a say :p |
| 18:01:39 | gradha | rndbit: yes, some editors cheat and use string based completion, like vim without plugins |
| 18:01:58 | rndbit | if i was a leet coder i would just make plugin for qtcreator instead of making completely separate editor |
| 18:02:11 | EXetoC | string-based BF completion must be awesome |
| 18:03:08 | rndbit | executable size nimrod produces is absolutely awesome btw |
| 18:03:13 | rndbit | w/ all optimizations ofc |
| 18:03:16 | gradha | maybe you can implement this qtcreator plugin for nimrod? |
| 18:03:36 | rndbit | told you if i was a leet coder.. :| |
| 18:03:46 | gradha | well, maybe you are just an awesome coder, who knows |
| 18:04:10 | EXetoC | the underlying C compiler produces it, but yes Nimrod generates the code |
| 18:04:23 | EXetoC | well, not C only |
| 18:04:46 | rndbit | actually im having thoughts about making h2nim (in python, dont hit me!) |
| 18:05:00 | Araq | yeah great |
| 18:05:04 | rndbit | from what i saw it should be pretty trivial to do |
| 18:05:11 | Mat2-coding | good luck |
| 18:05:25 | Araq | lets read no docs and instead reinvent c2nim |
| 18:05:29 | Araq | albeit poorly |
| 18:05:37 | Araq | ;-) |
| 18:05:38 | rndbit | i thought c2nim doesnt handle c++ |
| 18:05:48 | Araq | ah but h2nim does? :P |
| 18:05:58 | EXetoC | sure why not |
| 18:06:07 | * | Trixar_za is now known as Trix[a]r_za |
| 18:06:07 | EXetoC | maybe BF and algol as well |
| 18:06:16 | gradha | I heard h2nim uses clang like dao to produce automatic bindings |
| 18:06:19 | Mat2-coding | how about the false language ? |
| 18:06:26 | Araq | well I'll patch c2nim to support C++ one day |
| 18:06:36 | Araq | or you could do it |
| 18:06:45 | rndbit | there is c++ header parser module in python so it cant be hard doing that way |
| 18:07:11 | rndbit | im cheap bitch, going the easiest way possible |
| 18:07:28 | Mat2-coding | then take the assemby route |
| 18:07:31 | Mat2-coding | ^assembly |
| 18:07:41 | EXetoC | lolwut |
| 18:07:49 | Araq | and yet you assume people use the best tool for the job, rndbit ? ;-) |
| 18:07:56 | rndbit | yeah i can code in assembly. about gazillion times slower than in python :D |
| 18:08:05 | EXetoC | asm2nim? or an implementation in assembly? :o |
| 18:08:11 | EXetoC | rndbit: nub! |
| 18:08:23 | rndbit | totally nub! |
| 18:09:56 | Mat2-coding | assembly is the simplest yet possible way programming beside coding in hex-code |
| 18:10:47 | BitPuffin | Mat2-coding: well, vectors are pretty done but matrices aren't and I haven't added quaternions yet |
| 18:12:33 | Mat2-coding | BitPuffin: I will take a look at the sources (because need a decent verctor library) later |
| 18:12:47 | BitPuffin | Mat2-coding: you only need vectors? |
| 18:13:05 | Mat2-coding | no I also need matrices |
| 18:13:26 | BitPuffin | Mat2-coding: ah, well they work but they aren't complete |
| 18:13:41 | Mat2-coding | good :) |
| 18:42:20 | BitPuffin | okay time to finish this scrypt thing, then I am gonna make an xml-rpc library quickly |
| 18:45:02 | gradha | let a: uint8 = 253 |
| 18:45:13 | gradha | echo($cast[int8](a)) --> 253 |
| 18:45:23 | gradha | shouldn't that give me a negative number? |
| 18:51:42 | EXetoC | gradha: prints -3 |
| 18:52:46 | gradha | I guess it's macs which are crap then |
| 18:54:41 | gradha | oooh, nice bug, it's the REPL doing something wrong |
| 18:59:28 | gradha | EXetoC: thanks for testing, https://github.com/Araq/Nimrod/issues/573 |
| 18:59:44 | gradha | I was getting crazy trusting the interactive version |
| 19:01:07 | EXetoC | c(:) |
| 19:03:00 | gradha | BitPuffin: why not wrap around google protobuffers or something like that? |
| 19:04:29 | BitPuffin | gradha: hmm? |
| 19:05:08 | EXetoC | can only the first argument be something other than a proc when using the 'do' notation? |
| 19:07:55 | gradha | BitPuffin: isn't xml-rpc used for object serialization and stuff like that' |
| 19:09:02 | gradha | https://en.wikipedia.org/wiki/Xml-rpc#Criticism |
| 19:09:05 | EXetoC | ok it's the dot notation that doesn't work (x.y() do...) |
| 19:09:37 | gradha | BitPuffin: google uses https://code.google.com/p/protobuf/ instead of xml-rpc |
| 19:09:47 | EXetoC | Araq: is x.y() do... supposed to work? rather than y(x) do... |
| 19:12:07 | gradha | hah, look at the protocol names of https://en.wikipedia.org/wiki/Apache_Thrift#Architecture |
| 19:12:44 | EXetoC | :> |
| 19:13:47 | gradha | the name of the clojure xml-rpc client is good too https://github.com/brehaut/necessary-evil/ |
| 19:18:45 | EXetoC | Araq: can't see why not, but this might be caused by something else |
| 19:27:58 | EXetoC | yep |
| 19:36:22 | BitPuffin | gradha: but why would I do that? |
| 19:37:15 | gradha | writing an xml-rpc library seems like pain |
| 19:38:24 | * | Associat0r quit (Ping timeout: 276 seconds) |
| 19:40:05 | * | Associat0r joined #nimrod |
| 19:40:05 | * | Associat0r quit (Changing host) |
| 19:40:05 | * | Associat0r joined #nimrod |
| 20:03:57 | Araq | xml-rpc ? that's marshal + zeromq |
| 20:04:19 | Araq | gradha: weird, I thought I had successfully disabled 'cast' in the REPL for reasons like this |
| 20:04:45 | Araq | 'cast' is very hard to implement when you have a symbolic representation |
| 20:23:15 | gradha | macosx went full retard, can't watch a website with quicktime movies |
| 20:23:55 | Araq | steve jobs knows better than you and he knows quicktime movies are bad for your health |
| 20:24:07 | Araq | so he kindly disabled them |
| 20:24:18 | Araq | in fact ... |
| 20:24:27 | Araq | Steve knows computers are bad for you |
| 20:24:31 | Araq | so he made them useless |
| 20:27:30 | * | gradha_ joined #nimrod |
| 20:29:10 | * | gradha quit (Ping timeout: 245 seconds) |
| 20:35:02 | Mat2-coding | hey, its probably useless but looks nice and have many, many hidden surprises for endless entertainment |
| 20:36:02 | Araq | the truth is ... they couldn't even design the garbage can |
| 20:38:57 | Mat2-coding | who need to take a look at the garbage can if you have instead these high priced computer |
| 20:39:13 | Mat2-coding | (it even smells expensive) |
| 20:42:53 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 20:44:33 | gradha_ | awww, can't have strings longer than sizeof(int) |
| 20:45:23 | Araq | yeah |
| 20:45:23 | Araq | 4 bytes should be enough for every string |
| 20:46:03 | Mat2-coding | a 4 gB sized string ? |
| 20:46:43 | Mat2-coding | or a string of 4 bytes ? |
| 20:46:43 | * | EXetoC joined #nimrod |
| 20:46:53 | gradha_ | so how can I have a longer array? I tried https://github.com/Araq/Nimrod/issues/570 but can't seem to create one with a size specified by a variable |
| 20:47:43 | Araq | gradha_: indeed upper array bound needs to be a constant, use a 'seq' if you need a dynamic upper bound |
| 20:48:23 | EXetoC | maybe wrap it if you really need that behavior |
| 20:57:58 | BitPuffin | gradha_: well perhaps, but there is a need for it, you can't use google protobufs instead of xml-rpc when an api is xml-rpc |
| 21:01:23 | Mat2-coding | Araq: it seem only possible to assign signed values to uint64 variables. Is these a bug or a feature ? |
| 21:02:58 | Mat2-coding | found the reason: A typo |
| 21:02:58 | Mat2-coding | all ok |
| 21:03:13 | Araq | good |
| 21:03:23 | gradha_ | maybe 64bits are for hipsters, the following fails too https://github.com/Araq/Nimrod/issues/574 |
| 21:04:43 | Araq | gradha_: the error message is indeed a bit weird but did it ever occur to you 'int' is 64bits on a 64 bit system for these reasons? |
| 21:04:58 | Araq | there is no need to use 'int64' here and it would be wrong on a 32bit system ... |
| 21:05:58 | Araq | and so the compiler disallows it |
| 21:06:43 | gradha_ | but I don't want this code to compile on 32 bit systems, int is architecture dependant |
| 21:07:03 | gradha_ | maybe assert int == int64 or something like that? |
| 21:08:03 | Araq | when sizeof(int) == 4: {.error: "bah, I don't want you to able to compile this".} |
| 21:08:03 | gradha_ | or rather, I need to write different code paths for 32/64 bits |
| 21:08:18 | gradha_ | ok, will use that |
| 21:09:03 | gradha_ | what happens if I use an int64 and compile on a 32 bit machine? is it emulated or won't compile? |
| 21:09:23 | Araq | cpus can handle it these days |
| 21:09:43 | Araq | otherwise the C compiler would emulate it for us |
| 21:10:23 | * | gradha_ wonders if reactormonk calculates many things with 64bits on his arduino thingy |
| 21:11:43 | Mat2-coding | ok, following code: var test: uint64 = 0xF8F9FAFBFCFDFEFF. I get these error message - |
| 21:11:43 | Mat2-coding | Error: type mismatch: got (int literal(-506097522914230529)) but expected 'uint64' |
| 21:12:13 | Araq | try to add a 'u64 to the literal |
| 21:13:38 | Mat2-coding | Error: 0xF8F9FAFBFCFDFEFF is not a valid number |
| 21:13:53 | Araq | yay ... |
| 21:14:03 | reactormonk | gradha_, not gonna happen ^^ |
| 21:15:43 | Mat2-coding | wow, the tick was replaced with a control character in gedit !! |
| 21:16:38 | Mat2-coding | no compiler error so far |
| 21:16:53 | gradha_ | Mat2-coding: there's a reason you should be using Aporia instead of gedit |
| 21:17:43 | Araq | bbl |
| 21:20:18 | Mat2-coding | gradha_: that's a memory leak of the gtk lib as I can see so I'm not sure Aporia wouldn't be affected because the iDE uses gtksourceview, right ? |
| 21:22:18 | * | Mat2-coding is now known as Mat2 |
| 21:23:13 | Mat2 | I need some sleep, ciao |
| 21:23:23 | * | Mat2 quit (Quit: Verlassend) |
| 21:37:03 | * | gradha_ quit (Ping timeout: 240 seconds) |
| 21:44:13 | * | x-s4nd3r joined #nimrod |
| 21:49:53 | * | x-s4nd3r quit (Remote host closed the connection) |
| 21:53:03 | * | x-s4nd3r joined #nimrod |
| 22:05:53 | * | x-s4nd3r quit (Quit: i'll be back in a moment, just gotta do some stuff...) |
| 22:08:33 | * | OrionPK joined #nimrod |
| 22:09:23 | * | Associat0r quit (Quit: Associat0r) |
| 22:20:43 | * | EXetoC quit (Quit: WeeChat 0.4.1) |