00:05:06 | Varriount | dom96: You still up? |
00:09:21 | * | xenagi joined #nimrod |
00:20:13 | njoejoe | I nimrod c --debugInfo --lineDir:on helloworld.nim. and then gdb helloworld; if i then do "list" it shows me the contents of lib/system.nim. how do i get it to show helloworld.nim so that i can set a breakpoint inside of it? |
00:22:51 | * | ehaliewicz joined #nimrod |
00:23:21 | * | reactormonk joined #nimrod |
00:25:39 | * | ehaliewicz` quit (Ping timeout: 276 seconds) |
00:29:39 | njoejoe | and i have a proc named helloworld() but gdb says no such funtion helloworld if I try "break helloworld" |
00:36:02 | EXetoC | a parameter such as this "T: typedesc[uint8|uint16|uint32]" should be the same as [T:uint8...], right? the former doesn't let me do T(x) in the body. the workaround is to do "var dummy: T" and then convert like this: "dummy.type(x)" |
00:42:29 | Demos_ | just walk up the stack to whereever |
00:42:53 | Demos_ | helloworld is likely not a function, did you make proc helloworld() in helloworld.nim? |
00:43:48 | Demos_ | EXetoC: I am not sure anyone knows how the hell typedescs are supposed to work :D |
00:45:31 | * | ehaliewicz quit (Ping timeout: 252 seconds) |
00:52:43 | fowl | njoejoe, dont name the function the same as the module, also your function might get name mangled |
01:09:26 | * | q66 quit (Quit: Leaving) |
01:11:26 | * | brson quit (Quit: leaving) |
01:12:40 | * | hoverbear joined #nimrod |
01:27:39 | * | _broody joined #nimrod |
01:28:38 | * | BitPuffin quit (Ping timeout: 240 seconds) |
01:36:32 | * | _broody quit (Quit: WeeChat 0.3.7) |
01:49:53 | flaviu1 | http://merd.sourceforge.net/slides/mgp00001.html is a very nice language, besides its non-maintainedness |
02:35:27 | * | NimBot joined #nimrod |
02:54:22 | * | Varriount_ joined #nimrod |
03:00:41 | * | nande__ joined #nimrod |
03:01:43 | * | hoverbea_ joined #nimrod |
03:03:11 | * | Varriount quit (Ping timeout: 258 seconds) |
03:03:13 | * | nande_ quit (Ping timeout: 258 seconds) |
03:07:23 | * | Xuerian quit (Ping timeout: 252 seconds) |
03:07:24 | * | icebattle quit (Ping timeout: 252 seconds) |
03:07:29 | * | icebattl1 joined #nimrod |
03:08:28 | * | xenagi quit (Quit: Leaving) |
03:09:05 | * | hoverbear quit (*.net *.split) |
03:09:33 | * | Xuerian joined #nimrod |
03:15:38 | * | noam quit (*.net *.split) |
03:45:09 | * | BitPuffin joined #nimrod |
03:57:18 | * | noam joined #nimrod |
03:58:00 | * | Jesin joined #nimrod |
04:19:18 | * | flaviu1 quit (Ping timeout: 240 seconds) |
04:40:34 | * | flaviu1 joined #nimrod |
04:46:19 | * | flaviu1 quit (Ping timeout: 252 seconds) |
04:51:30 | * | Demos_ quit (Remote host closed the connection) |
05:05:10 | * | noam quit (*.net *.split) |
05:29:29 | * | nande__ quit (Read error: Connection reset by peer) |
05:51:17 | * | hoverbea_ quit () |
06:10:21 | * | Varriount_ is now known as Varriount |
06:11:09 | Varriount | Araq: Are will still supposed to be using TaintedString? Also, why was it used in the first place? |
06:11:23 | Varriount | *Are we stil |
07:03:03 | NimBot | Araq/Nimrod new_spawn 417b9f5 Araq [+0 ±10 -0]: 'parallel' statement almost working |
07:03:45 | Varriount | Araq: Also, I'm going through all the old issues again, testing the code examples to see which ones can be closed. |
07:09:35 | Araq | Varriount: what's wrong with TaintedString? |
07:09:58 | Araq | Varriount: please re-open #490 I think it's still an issue when the compiler runs in debug mode? |
07:10:25 | Varriount | Araq: I don't know. All that I've heard about TaintedString is that it helps with something concerning input validation. |
07:11:17 | Araq | yes, and it still does :-) |
07:11:27 | Varriount | Araq: Yes, but how exactly? |
07:11:39 | Varriount | "Input validation" is a rather generic term. |
07:11:47 | Araq | well use --taintMode:on and see for yourself |
07:23:01 | Araq | Varriount: in the taint mode TaintedString = distinct string and so you're forced to convert it to string before doing anything |
07:23:16 | Araq | this conversion is the point when you're supposed to do the input validation |
07:23:32 | Araq | works reasonably well, imho |
07:45:26 | * | noam joined #nimrod |
08:32:39 | * | ehaliewicz joined #nimrod |
09:26:49 | * | kunev joined #nimrod |
09:34:14 | * | Omermuneer joined #nimrod |
09:39:24 | Araq | hi Omermuneer welcome |
09:39:56 | Omermuneer | hows everyone here |
09:40:44 | Omermuneer | i was bored in my exams class, |
09:40:54 | Omermuneer | thought of using irc |
10:32:24 | * | Varriount|Mobile joined #nimrod |
10:34:04 | Varriount|Mobile | Omermuneer: I'm currently marvelling at the fact that I can play Nintendo 64 games on my phone. |
10:35:02 | Varriount|Mobile | That my phone has the surplus power to emulate a console is quite... surprising. |
10:35:50 | * | Omermuneer quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
11:02:49 | * | freezerburnv joined #nimrod |
11:41:19 | * | vendethiel quit (Read error: Connection reset by peer) |
11:47:14 | * | vendethiel joined #nimrod |
12:13:29 | * | untitaker quit (Ping timeout: 264 seconds) |
12:18:31 | * | untitaker joined #nimrod |
12:40:09 | * | BitPuffin quit (Ping timeout: 276 seconds) |
12:43:39 | * | ehaliewicz quit (Ping timeout: 258 seconds) |
12:53:49 | * | isenmann quit (Quit: Leaving.) |
13:02:28 | * | darkf quit (Quit: Leaving) |
13:08:06 | * | freezerburnv quit (Quit: freezerburnv) |
13:16:13 | dom96 | hellooo |
13:17:25 | * | devdri joined #nimrod |
13:22:24 | EXetoC | hi |
13:25:32 | Araq | hi devdri welcome |
13:25:35 | Araq | hi dom96, EXetoC |
13:25:43 | devdri | hi |
13:25:56 | dom96 | hey |
13:28:21 | devdri | great job, language looks super cool. Wanted to ask about the js backend usage, but I just found answer in the docs |
13:42:19 | * | OrionPK joined #nimrod |
13:48:13 | * | nealie joined #nimrod |
13:48:45 | Araq | hi nealie welcome |
13:49:04 | nealie | oh, hi. just checking out irc for my first time |
13:49:26 | nealie | i thpought i'd lurk here for a while and see if anything interesting happens |
13:50:10 | nealie | i wrote the FreeBSd port for Nimrod by the way, so i thought i should try and keep up to date |
13:59:31 | * | freezerburnv joined #nimrod |
14:40:05 | * | devdri quit () |
14:46:50 | * | devdri joined #nimrod |
15:13:37 | * | kunev quit (Quit: leaving) |
15:14:40 | * | BitPuffin joined #nimrod |
15:23:51 | * | kunev joined #nimrod |
15:53:47 | * | Matthias247 joined #nimrod |
16:02:48 | * | kunev quit (Quit: Lost terminal) |
16:04:14 | * | devdri_ joined #nimrod |
16:06:23 | * | devdri quit (Ping timeout: 252 seconds) |
16:14:13 | * | Matthias247 quit (Read error: Connection reset by peer) |
16:16:13 | * | hoverbear joined #nimrod |
16:16:32 | * | nequitans joined #nimrod |
16:18:43 | * | nealie quit (Quit: Leaving) |
16:37:51 | * | BitPuffin quit (Ping timeout: 265 seconds) |
16:38:11 | * | brson joined #nimrod |
16:38:13 | * | brson quit (Client Quit) |
16:38:20 | * | brson joined #nimrod |
16:39:59 | * | BitPuffin joined #nimrod |
16:43:26 | EXetoC | does anyone use msgpack? |
16:46:39 | EXetoC | people claim that it doesn't offer many benefits compared to gzipped json for example. I'll be wrapping it anyway |
16:51:01 | * | Demos_ joined #nimrod |
16:52:18 | Demos_ | so erm it looks like that underscore patch removes too many underscores from the generated code, or at least breaks code in interesting ways |
16:52:29 | Demos_ | I will try and debug it layer |
16:52:31 | Demos_ | *later |
16:53:47 | Demos_ | wait no, it is just that it seems some stuff was lowercased |
16:54:33 | Demos_ | I had a data member named Union and the C ident name is union, which is obviously a bit of a problem |
16:55:30 | dom96 | Field names shouldn't begin with an uppercased letter anyway, or at least they shouldn't in the future. |
16:56:33 | * | flaviu1 joined #nimrod |
16:57:12 | Demos_ | why not? |
16:57:26 | Demos_ | and field names in the generated C code or in nimrod code |
16:57:31 | dom96 | Nimrod code. |
16:57:40 | Demos_ | wait what.... |
16:57:58 | Demos_ | it should not matter |
16:58:18 | dom96 | Once the partial case sensitivity becomes default, if it does, then it will be this way. |
16:58:28 | dom96 | But yes, now it doesn't matter. |
16:58:49 | Demos_ | well I don't like the partial case sensitivity... but in this case it is just a bug |
16:59:00 | dom96 | But why is that a problem? |
16:59:11 | dom96 | Doesn't that make it easier to predict? |
16:59:23 | Demos_ | because having Union generate a c identifier named union means the C does not even compile |
16:59:51 | dom96 | I see. |
17:00:06 | dom96 | Bug report then. |
17:00:34 | dom96 | I'm guessing the C gen has some kind of list of idents which are C keywords. |
17:00:46 | dom96 | Perhaps it's just a case of adding 'union' to it in the compiler? |
17:01:59 | * | q66 joined #nimrod |
17:01:59 | * | q66 quit (Changing host) |
17:01:59 | * | q66 joined #nimrod |
17:02:56 | Demos_ | nope. It looks like the old mangleing would just emit upper case idents |
17:03:16 | Demos_ | all C keywords are lower case |
17:03:35 | Demos_ | I gotta go to a physics lab, but it should be an easy fix |
17:03:38 | dom96 | ahh, then it should be even easier to fix. |
17:07:55 | * | Demos_ quit (Ping timeout: 240 seconds) |
17:15:11 | EXetoC | I hate having to write less expressive code just to avoid some ICE :p |
17:19:15 | njoejoe | I found the video linked from this page: https://fosdem.org/2014/schedule/event/your_application_versus_gdb/ quite interesting. It's 50 minutes long. hoping a gdb expert can make nimrod debugging a joy :-) |
17:21:41 | njoejoe | I forsee aporia linked up with a nimrod aware gdb |
17:22:43 | dom96 | Debugging using gdb with --linedir:on and --debuginfo is already pretty good. |
17:27:02 | njoejoe | dom96: I couldn't get it useful for me. I think I need to do more reading. I couldn't figure out how to get to the listing of the program I was debugging... from gdb: "list" listed out system.nim or some such |
17:27:31 | dom96 | listing? |
17:30:31 | njoejoe | in gdb, typing "list". I expected it to list with line numbers the source for the program I was debugging, getting the line numbers to set breakpoints etc. |
17:31:04 | dom96 | Just open the .nim file in your editor and use it to determine the line numbers. |
17:33:22 | njoejoe | that doesn't work. i.e. gdb helloworld; then "break 5" : Breakpoint 1 at 0x40c959: (...)/Nimrod/lib/system.nim:5. (3 locations) |
17:33:37 | dom96 | break file.nim:5 |
17:34:03 | njoejoe | ah! thanks. |
17:35:05 | njoejoe | still i did find the video fascinating, esp near the end where he was debugging gcc and showing control flow graphically |
17:36:15 | njoejoe | starting at around minute 41 |
17:36:16 | EXetoC | gdb -tui is alright |
17:37:08 | * | brson_ joined #nimrod |
17:40:41 | * | brson quit (Ping timeout: 265 seconds) |
17:42:15 | njoejoe | EXetoC: -tui is pretty cool, didn't know about it. Is there a way to cause it to list the contents the the mainfile of your nimrod program when it starts? I don't want it to start with system.nim |
17:56:04 | * | brson_ quit (Quit: leaving) |
17:56:11 | * | brson joined #nimrod |
18:01:33 | EXetoC | no idea. haven't used it for nimrod code |
18:04:55 | EXetoC | I assume you are ok with me creating an msgpack repository in nimrod-code |
18:06:16 | EXetoC | but can we please not use the same names as the original C libs |
18:08:26 | EXetoC | I strongly prefer unique names in general |
18:11:29 | Araq | EXetoC: sometimes examples help |
18:11:49 | Araq | what ames do you want to change? |
18:11:55 | Araq | *names |
18:13:43 | * | Varriount|Mobile quit (Remote host closed the connection) |
18:14:44 | * | askatasuna joined #nimrod |
18:25:30 | EXetoC | Araq: the names of all wrappers that share the same name as the original C lib: x11, cairo, python... a nim- prefix is fairly common, and in many cases you want to distinguish between the two, without having to rename locally or introduce a new sub-directory for example |
18:26:10 | EXetoC | obviously it didn't matter before because they were a part of the nimrod distribution |
18:26:40 | EXetoC | I brought this up before, but I don't know if I got my point across |
18:27:48 | EXetoC | dom96: do any non-wrappers use the prefix? since you complained about the prefix before |
18:28:05 | EXetoC | that seems unlikely |
18:28:41 | dom96 | nimbuild, nimforum |
18:28:43 | dom96 | nimkernel |
18:30:53 | EXetoC | you don't like that? they're either specifically for the nimrod ecosystem or a showcase for the language |
18:32:06 | * | dom96 shrugs |
18:33:07 | EXetoC | I just recalled that you said something along those lines, though you did say that you didn't have a problem with the prefix for wrappers |
18:34:48 | EXetoC | Am I the only one who has lost my forum password? :p |
18:35:00 | dom96 | lol |
18:35:46 | * | Varriount|Mobile joined #nimrod |
18:37:41 | Varriount|Mobile | Araq: Have compile-time event hooks been considered? So that a library or program may set certain procedures to run after events such as when the executable is produced? |
18:47:18 | Araq | Varriount|Mobile: not really |
18:47:25 | * | ehaliewicz joined #nimrod |
18:48:14 | Varriount|Mobile | Araq: I ask because I'm trying to figure out how to include a manifest in a Nimrod executable |
18:48:55 | Araq | meh why do you want to do that? |
18:49:59 | Araq | koch.nim shows how to embed resources |
18:50:23 | Varriount|Mobile | Araq: I don't know if straight embedding will work |
18:51:01 | Varriount|Mobile | Araq: I want to do it in order to bring up the UAC prompt when users run my program |
18:57:20 | Araq | ok good |
18:57:29 | Araq | no idea how this is accomplished though |
19:08:37 | flaviu1 | Araq: There's a lot a keywords, is there any chance that that list can be decreased in size? `atomic`, `converter`, `interface`, `lambda`, `out`, and `without` seem to be unused ATM |
19:09:08 | fowl | Varriount|Mobile, gradha has something for that |
19:09:33 | Araq | number of keywords as a measure for language complexity is braindead, flaviu1 |
19:09:49 | fowl | Varriount|Mobile, ouroboros |
19:10:13 | flaviu1 | Araq: That isn't my thinking, it just sucks not to be able to use the identifier you want. |
19:10:14 | * | Matthias247 joined #nimrod |
19:10:44 | Araq | we can get rid of 'atomic' and 'lambda', but 'out' and 'without' are too useful and will be used eventually as keywords |
19:12:08 | flaviu1 | Araq: How about `end`? I don't think that's used |
19:12:26 | Araq | that is used for #end if in .tmpl files |
19:12:46 | Araq | also it's reserved for an alternative 'end X' syntax |
19:13:07 | fowl | ew thats it means by endx? |
19:13:25 | fowl | is "end if" more clear than "end"? :( |
19:13:56 | flaviu1 | The first application should be done by the library, but the second is fair enough I guess |
19:15:46 | Araq | fowl: 'end if' vs 'end' ... both are possible, don't worry |
19:16:17 | Araq | brb |
19:18:16 | flaviu1 | I think that could be better done with a custom parser instead of in the code language, but I won't loose too much sleep over that |
19:18:23 | flaviu1 | s/code/core/g |
19:19:59 | Araq | well interop between different parsers is the issue here |
19:20:14 | EXetoC | flaviu1: converter? |
19:20:17 | Araq | how do you use my 'end' identifier in the alternative syntax? |
19:20:33 | EXetoC | nvm |
19:20:42 | Araq | `end` in backticks is annoying |
19:20:44 | Araq | brb |
19:20:57 | * | Mat3 joined #nimrod |
19:21:03 | Mat3 | good afternoon |
19:21:42 | fowl | Araq, i think he means it shouldnt be a keyword in the normal syntax |
19:21:59 | EXetoC | flaviu1: converter is used for.. converters |
19:22:56 | flaviu1 | fowl: Araq understands that, what he's saying is how my having an identifier `end` in standard nimrod will behave in PascalNimrod |
19:23:09 | flaviu1 | EXetoC: I'm not sure what you're saying |
19:23:35 | * | devdri_ quit () |
19:24:02 | EXetoC | unused where? in the compiler distribution? it's used elsewhere |
19:24:07 | fowl | flaviu1, the othersyntax would have to `escape` it, not a big deal imo |
19:24:41 | Varriount | Aha! Thank you internets: http://cournape.wordpress.com/2008/09/02/how-to-embed-a-manifest-into-a-dll-with-mingw-tools-only/ |
19:25:32 | flaviu1 | fowl: My opinion too, if you pick a different parser, deal with it, you made the decision |
19:25:51 | flaviu1 | EXetoC: Are you talking about templates? |
19:26:00 | EXetoC | flaviu1: converters |
19:26:23 | fowl | Varriount, https://github.com/gradha/nimrod-ouroboros |
19:26:38 | EXetoC | asyncio.nim and a couple of tests use it |
19:27:43 | Varriount | fowl: Won't work. |
19:27:59 | EXetoC | ah yes there's my project in manyloc |
19:28:14 | fowl | Varriount, oh |
19:28:20 | EXetoC | huge test case for a simple bug |
19:29:13 | fowl | Varriount, that looks annoying |
19:29:50 | flaviu1 | EXetoC: I can't find anything except .tmpl files, which use a custom parser anyway. |
19:30:34 | EXetoC | flaviu1: are we not talking about keywords in general? |
19:30:45 | EXetoC | most of my projects have converter "procs" |
19:31:59 | flaviu1 | Is converter an alias for proc? |
19:32:17 | Varriount | flaviu1: In a way. |
19:32:38 | EXetoC | apparently it's barely documented |
19:32:45 | flaviu1 | Implicit procs? |
19:32:50 | EXetoC | http://build.nimrod-lang.org/docs/manual.html#convertible-relation |
19:33:14 | * | devdri joined #nimrod |
19:33:21 | Varriount | Hi devdri |
19:33:22 | EXetoC | look for converter in the last code section |
19:33:37 | devdri | hi |
19:33:47 | flaviu1 | EXetoC: Ok, keep converter then, although it could hypotheticly be a macro pragma |
19:33:47 | EXetoC | it's a way to define implicit conversions |
19:34:09 | EXetoC | maybe |
19:35:10 | EXetoC | maybe someone wants to discuss the naming of wrappers on the forums, because I can't, and questions get lost here |
19:36:31 | Varriount | EXetoC: Why can't you start a topic on the forum? |
19:37:06 | EXetoC | because I don't have my password |
19:37:19 | Varriount | -_- |
19:38:21 | EXetoC | I think it's good that we eat our dog food, but there's a lack of manpower |
19:38:55 | Varriount | EXetoC: Get dom96 to tell you the password hashing scheme, generate a new password and has it, then have dom96 replace your old password hash with the new one. |
19:39:06 | Varriount | *and hash it |
19:39:47 | flaviu1 | dom96: getMD5(salt & getMD5(password)) :/ |
19:42:22 | Araq | EXetoC: alternatively re-register as EXetoC2 or something |
19:42:56 | Varriount | Or maybe dom96 can delete his account from the database? |
19:43:24 | Mat3 | Araq; should I write something more to this: http://forum.nimrod-lang.org/t/448 ? |
19:44:55 | * | Jesin quit (Quit: Leaving) |
19:45:12 | EXetoC | yes, my nick is.. ventor3000, and that's the truth |
19:45:14 | Araq | Mat3: sure why not, though you can also simply post what you wrote to some other guy about low level stuff |
19:46:28 | Mat3 | ok |
19:48:09 | flaviu1 | dom96: When someone hacks into the database, they're getting all the passwords handed to them on a silver platter |
19:48:28 | * | Mat3 founds the rule to 'never ever using bit sets in C' quite useful |
19:49:32 | Mat3 | (alias bit-fields) |
19:50:29 | Araq | flaviu1: yes but they are salted and MD5'ed :P |
19:50:32 | EXetoC | so was the guy right about the fact that LLVM can generate efficient exception handling? I can't remember who you discussed this with |
19:51:00 | Araq | yes that is correct, EXetoC |
19:51:27 | EXetoC | and what about optimizations? when comparing LLVM with writing something from scratch |
19:51:37 | Varriount | flaviu1: Pft. I think I have a copy of the DB on my desktop, and it's not like any of your accounts have been stolen. |
19:51:41 | flaviu1 | Araq: 5 Billion MD5 Hashes per second |
19:52:07 | flaviu1 | For a single GPU, another will double it |
19:52:30 | Varriount | flaviu1: Good, you can work on making the forum more secure. :3 |
19:53:41 | Araq | flaviu1: well yes. it's a rarely used *forum* though, not your bank account |
19:54:49 | Mat3 | EXetoC: Comparing machine-code generated from LLVM with hand written code shows some problems with stack addressing (at least the last time I checked it) |
19:55:29 | EXetoC | right |
19:56:11 | Araq | also it has been written by some strange guys who rather spend their time on developing compilers and IDEs |
19:56:43 | flaviu1 | Araq: People resuse passwords, so its important. Also, fixing it takes no more than swapping md5 for bcrypt |
19:58:01 | * | Vendethiel- joined #nimrod |
19:58:24 | Mat3 | it's quite a large and complex code base for an IL compiler so personally I see no advantages against writing a simple code generator well suited for a specific task |
19:58:29 | * | vendethiel quit (Ping timeout: 252 seconds) |
19:59:40 | Mat3 | (and libJIT seem to have the better - code efficient - interface) |
20:00:29 | EXetoC | ok |
20:00:56 | EXetoC | Mat3: anyway, you should finish it in about a month or so, just to prove Araq wrong when he said it was years away :-) |
20:01:05 | EXetoC | flaviu1: yeah well someone's got to do it |
20:01:12 | Mat3 | *lol* |
20:01:39 | Mat3 | EXetoC: right |
20:03:18 | Mat3 | ciao |
20:03:25 | * | Mat3 quit (Quit: Verlassend) |
20:03:29 | flaviu1 | EXetoC: Working on a pull request right now |
20:03:49 | flaviu1 | At least there aren't any obvious sql injection issues |
20:04:33 | Araq | flaviu1: your help really is appreciated, thank you very much |
20:13:22 | dom96 | flaviu1: If it wasn't for me there wouldn't even be a salt :P |
20:15:36 | flaviu1 | dom96: Well, that's reassuring :O |
20:18:04 | dom96 | Also, it's not a simple case of s/getMD5/getBCrypt/ |
20:22:38 | flaviu1 | dom96: Pretty close though; try MD5, if it succeeds, rehash with BCrypt and store, otherwise try BCrypt |
20:23:25 | flaviu1 | dom96: Even easier actually. How big is the database? |
20:23:33 | dom96 | Wouldn't it be better to just ask the user to reset their password? |
20:24:35 | flaviu1 | dom96: Yes, that would be better. But chances are that almost no one will bother, and the security should be extended retroactively as much as possible. |
20:25:26 | flaviu1 | If the database is fairly small, you can just hash every password with BCrypt on top of MD5 and save some complexity |
20:28:29 | flaviu1 | runvnc just implemented the most broken possible hash function and called it bcrypt :/ |
20:29:00 | Varriount | -_- |
20:29:18 | flaviu1 | It looks like he's encrypting the password with the salt |
20:29:52 | dom96 | I guess that will work... but it'll be inefficient. |
20:30:14 | Varriount | dom96: Isn't that the point? |
20:30:19 | flaviu1 | dom96: The whole goal of bcrypt is to be slow |
20:30:37 | * | nande_ joined #nimrod |
20:30:51 | flaviu1 | but that's irreverent, what he calls bcrypt is just a fancy way of storing passwords in plaintext |
20:32:45 | * | boydgreenfield joined #nimrod |
20:33:46 | Varriount | flaviu1: I take it you're referencing runvnc's 'bcrypt'? |
20:34:00 | flaviu1 | Varriount: Yes |
20:34:40 | Varriount | flaviu1: Is it meant to be an implementation of the actual bcrypt, or is it just a nameing coincidence/collision? |
20:35:09 | flaviu1 | "This is a Nimrod wrapper for the bcrypt C functions" "bcrypt is useful for hashing passwords" |
20:37:34 | Varriount | flaviu1: What's specifically wrong with the package? |
20:40:36 | * | boydgreenfield quit (Quit: boydgreenfield) |
20:45:04 | * | Varriount|Mobile quit (Remote host closed the connection) |
20:48:37 | * | devdri quit () |
20:49:31 | * | Varriount|Mobile joined #nimrod |
20:49:33 | * | foxcub joined #nimrod |
20:51:29 | * | devdri joined #nimrod |
20:54:53 | Araq | hmm I've implemented dataflow variables ... |
20:54:54 | * | Varriount|Mobile quit (Remote host closed the connection) |
20:55:03 | Araq | but they simply crash ... |
20:55:08 | * | Varriount|Mobile joined #nimrod |
20:55:22 | flaviu1 | Varriount: Crappy method name suggests that it just reversibly encrypts the password with the salt but the implmentation looks like its actually hashing, I have no idea what to think, except that I don't like it. It's also from 1997, so I'm not confident its still good, especially since IIRC there have been flaws found. |
21:04:25 | * | freezerburnv quit (Quit: freezerburnv) |
21:51:04 | * | Matthias247 quit (Read error: Connection reset by peer) |
22:09:13 | * | freezerburnv joined #nimrod |
22:25:10 | * | brson quit (Ping timeout: 258 seconds) |
22:26:09 | * | foxcub quit (Quit: foxcub) |
22:38:56 | * | brson joined #nimrod |
22:45:24 | * | Demos_ joined #nimrod |
22:50:11 | * | devdri quit (Ping timeout: 252 seconds) |
22:52:33 | * | devdri joined #nimrod |
22:58:46 | * | tylrr joined #nimrod |
23:01:40 | * | tylrr left #nimrod ("Textual IRC Client: www.textualapp.com") |
23:07:06 | * | freezerburnv quit (Quit: freezerburnv) |
23:16:30 | * | ehaliewicz quit (Ping timeout: 276 seconds) |
23:21:48 | * | devdri_ joined #nimrod |
23:23:41 | * | devdri quit (Ping timeout: 264 seconds) |
23:28:41 | * | darkf joined #nimrod |
23:29:03 | flaviu1 | Not nimrod, but Clang says "please include the header <string.h>", but I do have a `#include <string.h>` |
23:29:37 | EXetoC | does the order matter? |
23:29:39 | * | hoverbear quit () |
23:29:58 | flaviu1 | IDK, but I don't think so |
23:31:27 | flaviu1 | Apparently linux doesn't include a strcpy |
23:33:07 | * | Demos_ quit (Ping timeout: 240 seconds) |
23:35:12 | * | Demos_ joined #nimrod |
23:41:45 | Varriount|Mobile | flaviu1: So if you don't trust bcrypt, what password hashing method do you recommend? |
23:42:37 | flaviu1 | Varriount|Mobile: I don't really trust that implmentation, especially since it doesn't have any comments describing the method. I'm looking into adapting the BSD bcrypt |
23:43:45 | flaviu1 | Also, minor flaws have been found and fixed since 1997 |
23:57:30 | * | xenagi joined #nimrod |
23:57:42 | Demos_ | flaviu1, you are the author of PR #1204 right? |