| 00:00:23 | nimnoob | thanks :) |
| 00:01:29 | flaviu | vim, although I don't recommend it. It doesn't asynchronously call the compiler, so everything locks up. |
| 00:03:46 | * | dts|pokeball joined #nim |
| 00:05:25 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:17:37 | * | drewsrem quit (Quit: Leaving) |
| 00:18:40 | * | z1y quit (Ping timeout: 244 seconds) |
| 00:21:12 | nimnoob | anyone familiar with this error? "inheritance only works with non-final objects" |
| 00:21:46 | nimnoob | i am creating a type which extends a ref object type |
| 00:21:46 | dts|pokeball | why not post your code and your full error? |
| 00:21:50 | nimnoob | k |
| 00:27:07 | nimnoob | http://pastebin.com/NejHyZEF |
| 00:27:26 | nimnoob | i create a ref object type, PDrawable |
| 00:27:45 | nimnoob | and then try to inherit from that type as PTestDrawable |
| 00:29:41 | nimnoob | got it: Objects which do not inherit from TObject are now by default final. |
| 00:29:45 | nimnoob | :( |
| 00:29:59 | nimnoob | sorry, my googling has failed me |
| 00:31:01 | nimnoob | adding "of TObject" to the declaration of PDrawable fixed the issue |
| 00:41:07 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 00:45:03 | * | Mat4 left #nim (#nim) |
| 00:53:57 | ldlework | Araq: why do you use aporia if its Nim features don't work? |
| 00:54:40 | * | gokr2 quit (Ping timeout: 246 seconds) |
| 00:54:47 | nimnoob | what do you use idlework? |
| 00:55:58 | flaviu | ldlework: You should see his color scheme too! |
| 00:56:13 | ldlework | nimnoob: for nim? sublime 2. |
| 00:56:15 | dom96 | ldlework: Which editor's Nim features do work? |
| 00:56:27 | EXetoC | I can't wait for capable symbol browsing etc, and autocompletion, which some people think is bad apparently :o |
| 00:56:28 | ldlework | dom96: none! |
| 00:56:31 | EXetoC | in general |
| 00:56:53 | ldlework | EXetoC: didn't Aporia do Nim completion until idetools broke? |
| 00:56:58 | dom96 | It did. |
| 00:57:25 | EXetoC | oh, well I'd have to wait for other editor features that I can't do without, but that's good to know |
| 00:57:37 | EXetoC | how well did it work? |
| 00:57:40 | ldlework | EXetoC: like emacs bindings and macros that include search operations? |
| 00:59:42 | dom96 | EXetoC: Not good enough. |
| 01:00:05 | * | gmpreussner joined #nim |
| 01:01:48 | EXetoC | ldlework: I prefer vim, but yes better keyboard editing in general |
| 01:02:18 | EXetoC | dom96: obviously I want something that works fairly well :p but it will work well eventually |
| 01:02:49 | dom96 | EXetoC: Improve it. It is open source after all. |
| 01:04:25 | ldlework | I think a Nim specific editor is a losing bet |
| 01:05:01 | EXetoC | we have decent support for several other editors though |
| 01:05:16 | ldlework | Yeah but what's the point |
| 01:05:22 | ldlework | oh |
| 01:05:25 | EXetoC | including lighttable. I don't think many has tested that plugin |
| 01:05:32 | ldlework | I read that as "support for other languages" |
| 01:05:40 | EXetoC | but no plugin does anything special, I think |
| 01:06:09 | flaviu | EXetoC: You use the vim nim plugin? How do you put up with the compiler pauses? |
| 01:06:26 | * | nande_ joined #nim |
| 01:07:11 | EXetoC | I haven't experienced long pauses yet |
| 01:07:36 | flaviu | I haven't either, but the short pauses are very annoying still. |
| 01:07:49 | EXetoC | but can the compiler be run from vim asynchronously? waiting for the compiler is a bitch |
| 01:08:31 | flaviu | That's exactly my question. I wish the neovim people were done already :P |
| 01:08:42 | ldlework | no one is even rewriting emacs :( |
| 01:08:45 | EXetoC | but lighttable has a vim plugin, and it allows for async execution surely |
| 01:09:08 | EXetoC | right, neovim |
| 01:09:47 | flaviu | I'm using someone else's vim config, so my vim is highly customized. Not sure that I want to deal with poor emulation with lightable. |
| 01:11:41 | * | dom96 quit (Changing host) |
| 01:11:41 | * | dom96 joined #nim |
| 01:12:12 | EXetoC | it should improve at some point. it was at least usable for me 6-7 months ago |
| 01:13:27 | flaviu | I was unable to use it last time I tried, but that might be because I have a ton of someone else's plugins ;) |
| 01:47:56 | * | Trustable quit (Quit: Leaving) |
| 02:04:48 | * | z1y joined #nim |
| 02:11:17 | * | jasondotstar joined #nim |
| 02:11:19 | * | z1y quit (Remote host closed the connection) |
| 02:12:03 | Araq | ldlework: dog fooding, I like its search&replace, it has syntax highlighting |
| 02:12:07 | * | z1y joined #nim |
| 02:13:02 | flaviu | Araq: Have you tried sed-style expressions? |
| 02:13:22 | Araq | not really |
| 02:13:33 | EXetoC | dom96: well I'm the all-talk-no-action guy, but it wasn't so much a complaint |
| 02:13:38 | Araq | but I have a couple of ideas of how to improve aporia |
| 02:13:53 | ldlework | even better then sed-style expressions are nonce macros that support search operations |
| 02:14:12 | flaviu | "nonce macros"? |
| 02:14:23 | Araq | hrm I wonder if we can close https://github.com/Araq/Nimrod/issues/1496 by setting the limit to 50 |
| 02:14:36 | ldlework | flaviu: press special start key, perform actions, press special end key |
| 02:14:54 | ldlework | flaviu: now press special 'repeat last macro' key as many times as you want until you define a new macro |
| 02:14:57 | Araq | the proper solution is too much work |
| 02:15:29 | flaviu | ldlework: But how does that do searching? |
| 02:15:30 | Araq | ldlework: so visual basic/microsoft macros? |
| 02:15:55 | flaviu | btw, vim does support that. qa<macro keypresses>q. Then @@ |
| 02:15:59 | ldlework | flaviu: one of the things you can do in a macro is an incremental search |
| 02:16:22 | ldlework | macros that support incremental search are -insanely- powerful |
| 02:16:55 | Araq | ldlework: hrm? not sure what you mean |
| 02:17:10 | ldlework | Imagine you are making a macro to make an edit on some regularly formatted text |
| 02:17:12 | ldlework | like functions |
| 02:17:46 | ldlework | you can imagine using movement to go from the start of the function name, to the parameter list for example |
| 02:17:54 | ldlework | but if you can incremental search |
| 02:18:01 | ldlework | you can just search for the next parens |
| 02:18:15 | ldlework | this allows your macro to work against functions with varying name length and so on |
| 02:18:36 | flaviu | Ok, but regexes are really really great. I'd rather write a regex to do the replacement than a macro. |
| 02:18:51 | ldlework | flaviu: macros can do things that regex simply can't |
| 02:19:01 | ldlework | and a macro is natural |
| 02:19:06 | ldlework | you simply do it to one function manually |
| 02:19:10 | ldlework | and the macro the rest |
| 02:19:12 | ldlework | also |
| 02:19:17 | boydgreenfield | flaviu: thoughts? not in love with the tables, but that’s easy enough to tweak: http://a.pomf.se/gdqrpd.html |
| 02:19:19 | ldlework | the best thing I haven't mentioned yet |
| 02:19:34 | ldlework | if you /end your macro with an incremental search for the next place you'd invoke the macro/ |
| 02:19:43 | ldlework | then you can just repeat the 'do macro' key |
| 02:19:50 | ldlework | rather than repositioning in the new macro start position |
| 02:20:19 | boydgreenfield | https://github.com/boydgreenfield/Nimrod/tree/improved-doc-styling |
| 02:21:47 | boydgreenfield | (I need to look back at the colors when it’s light out – bright screen + f.lux on + f.lux off + bad monitor + etc. makes this really hard) |
| 02:22:12 | boydgreenfield | Araq: Would love your thoughts as well. |
| 02:23:21 | EXetoC | Araq: any thoughts on having abstractions related to writing C libs (without relying on our runtime), and having an object system and API for generating bindings to other languages? |
| 02:24:21 | EXetoC | ideally you'd be able to write a high level Nim interface at the same time |
| 02:24:53 | flaviu | boydgreenfield: Helvetica is really pretty. A few issues: inline code is not monospace, previously clicked links do not darken, bold is too thick. |
| 02:24:54 | flaviu | Instead of striping the tables, just darken the header and use css tr:hover to highlight things. |
| 02:25:09 | EXetoC | I should ask on the forums |
| 02:25:37 | EXetoC | or forum |
| 02:25:50 | boydgreenfield | flaviu: All great suggestions. Do you like :visited darkened? I have mixed feelings for this kind of case (most things are internal anchors) |
| 02:25:59 | Araq | EXetoC: dunno what an object system would look like. python ruby and lua for instance dictate the object system already |
| 02:26:07 | boydgreenfield | good catch re: monospace, and agreed re: table |
| 02:26:36 | Araq | EXetoC: "C libs without our runtime" is what os:standalone provides |
| 02:27:05 | Araq | I suppose it needs a bit more polish but we're in good shape already |
| 02:27:06 | flaviu | boydgreenfield: Yes. Apparently usability studies show that people tend to go in circles if the links don't darken. I don't think that the anchors being darkened is really that big of a deal, I doubt it'd cause any confustion. |
| 02:27:11 | EXetoC | Araq: it would include some high level information not present in the C type system |
| 02:27:29 | boydgreenfield | flaviu: Can you point me to a a piece of non-monospace inline code? |
| 02:27:34 | EXetoC | yes and a couple of abstractions on top for working with good old error code checking and such |
| 02:28:18 | Araq | like making you check return values unless it's marked .discardable ... wait |
| 02:28:26 | Araq | we already do that :P |
| 02:28:39 | flaviu | boydgreenfield: you're right, but the inline monospace font is different from the block code font. |
| 02:28:54 | boydgreenfield | flaviu: Ah it is indeed. K thx. |
| 02:29:41 | Araq | EXetoC: a "check" template is not hard either and the type system is already much better than C's. For instance Nim knows that a pointer is not necessarily a pointer to an array |
| 02:30:59 | flaviu | Yeah, font-weight: bold looks cartoonish with Helvetica. 600 is much better IMO. |
| 02:31:58 | EXetoC | Araq: I meant error codes as opposed to exceptions, because of the aforementioned runtime requirements |
| 02:34:43 | * | kniteli quit (Read error: Connection reset by peer) |
| 02:35:33 | Araq | EXetoC: well it depends on what you want to do. write a python extension? then you know how to map exceptions etc. already |
| 02:35:50 | Araq | not much point in having some abstract thingie that tries to guess these things |
| 02:36:03 | EXetoC | well yes, which is why it'd be tempting to write C libs using Nim. I don't know how many people who already know Nim will want to do such a thing though, and plenty of libs are already written directly in C |
| 02:36:28 | Araq | well gradha does exactly that |
| 02:36:58 | Araq | but yeah, just ask on the forum please |
| 02:37:32 | EXetoC | does he have any abstractions for that on github? |
| 02:38:09 | Araq | dunno |
| 02:39:14 | boydgreenfield | flaviu: You mean at the top, in the headers, or in the body text w/r/t font-weight? |
| 02:39:33 | flaviu | boydgreenfield: The body text |
| 02:39:45 | boydgreenfield | flaviu: agreed, ok. |
| 02:40:14 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 02:40:15 | EXetoC | gradha might have some input then |
| 02:43:02 | * | vendethiel joined #nim |
| 02:44:33 | Araq | good night |
| 02:44:40 | EXetoC | Araq: do you know for what purpose? |
| 02:44:48 | EXetoC | ok cya |
| 02:48:07 | onionhammer1 | nimnoob - use sublimetext and NimLime |
| 02:56:11 | nimnoob | i currently do |
| 02:56:45 | nimnoob | it works fine, i just wondered what other, possiby better, options there are |
| 02:57:39 | * | darkf joined #nim |
| 03:01:45 | * | pwernersbach joined #nim |
| 03:03:00 | pwernersbach | What is the best way to do pointer arithmetic? |
| 03:03:57 | pwernersbach | I need to pack a byte buffer that has a variable size, and array[i, type] doesn't work when i isn't known at compile time |
| 03:05:03 | willwillson | you can have an unchecked array? |
| 03:05:25 | pwernersbach | What's the syntax for that? |
| 03:05:36 | willwillson | type CArray {.unchecked.} = array[0..0,type] |
| 03:06:24 | boydgreenfield | flaviu: Ok – http://a.pomf.se/gsvnzv.html |
| 03:07:39 | * | Varriount|Mobile joined #nim |
| 03:07:52 | nimnoob | pwernersbach, could you use openarray? |
| 03:08:55 | willwillson | I think fowl has a pointer arthimetic library as well |
| 03:09:08 | boydgreenfield | flaviu/Araq: Will be back in a few. Happy to make other tweaks and then I’ll do a PR for further comment there. |
| 03:09:21 | pwernersbach | willwillson: Thanks! Is there a way to have it checked? I know the size at runtime, but the compiler won't accept a runtime variable as the size. |
| 03:10:10 | flaviu | boydgreenfield: Hmm, I've never liked how clicking on the header gives you a link anchor to the toc. Could that be changed so that it gives a link to the header? I can't see any use case where linking to the TOC is desirable. |
| 03:10:22 | flaviu | Other than that, looks good to me. |
| 03:10:23 | pwernersbach | nimnoob: I have to get a C array from it, which I think rules out openarray |
| 03:10:36 | * | brson quit (Quit: leaving) |
| 03:10:44 | boydgreenfield | flaviu: Probably — but that may be in rstgen.nim – I haven’t looked deeply yet, but can poke around a bit. |
| 03:11:02 | willwillson | pwernersbach: can't you use a seq? |
| 03:11:05 | boydgreenfield | (My thinking is best not to really muck around there in case anybody has downstream dependencies, but that nimdoc.cfg should be fairly safe to change) |
| 03:12:29 | pwernersbach | willwillson: Can you convert a seq to a C array? |
| 03:12:47 | boydgreenfield | flaviu: Oh, I see what you’re saying – is there a reason to have it link at all? (Doesn’t need to link to itself) |
| 03:12:51 | willwillson | pwernersbach: yeah, take the memeory address of the 0th element |
| 03:13:14 | willwillson | pwernersbach: you are passing this a c function right? |
| 03:13:46 | flaviu | boydgreenfield: Yes, so that you can click on the header and send people links like http://a.pomf.se/gsvnzv.html#triple-quoted-string-literals |
| 03:13:54 | pwernersbach | willwillson: Yeah, I'm packing it in Nim and sending it to net.send, which takes a C array |
| 03:13:57 | flaviu | so they arrive in the section that you want them to. |
| 03:14:01 | boydgreenfield | flaviu: Indeed. |
| 03:15:09 | willwillson | pwernersbach: the only caveat is that you shouldn't resize it whilst the c code has its address, as this can cause it to be moved in memory |
| 03:15:35 | Varriount|Mobile | pwernersbach: Just make sure the sequence doesn't change size, otherwise it might be moved. |
| 03:17:34 | pwernersbach | willwillson Varriount|Mobile: Thanks for the tips |
| 03:18:08 | nimnoob | can you pin something in memory? |
| 03:18:25 | pwernersbach | Is there a way for me to specify the size of the sequence? Since I know the size I'd hate to lose the performance from the seq resizing |
| 03:18:29 | nimnoob | or is not changing the size good enough |
| 03:18:45 | willwillson | newSeq[type](size) |
| 03:18:55 | willwillson | pwernersbach: ^ |
| 03:18:55 | Varriount|Mobile | pwernersbach: If it can move, either copy the seq, or copy it into a proper array. |
| 03:20:18 | pwernersbach | Thanks everyone, I'll ensure it doesn't move |
| 03:20:47 | pwernersbach | This really helps, that should be in the documentation |
| 03:21:22 | pwernersbach | nimnoob: I don't think there's a way to pin something. You really can't ensure a pin if you use reallloc() anyways |
| 03:21:29 | boydgreenfield | flaviu: Lovely, appears hard-coded. https://github.com/boydgreenfield/Nimrod/blob/improved-doc-styling/lib/packages/docutils/rstgen.nim#L690 |
| 03:21:33 | * | dyu joined #nim |
| 03:22:06 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 03:37:37 | * | Hexagon joined #nim |
| 03:37:40 | * | boydgreenfield joined #nim |
| 03:38:16 | * | Hexagon quit (Client Quit) |
| 03:39:17 | flaviu | should be an easy fix though: s/2_toc/2/ |
| 03:39:27 | * | Hexagon joined #nim |
| 03:40:09 | boydgreenfield | flaviu: Ya, it’s easy. I just don’t like changing library code when it’s possible to change config code (though I can’t see this breaking anything). |
| 03:40:26 | * | zebra111 quit (Ping timeout: 258 seconds) |
| 03:45:57 | * | kapil__ joined #nim |
| 03:50:01 | * | nimnoob quit (Ping timeout: 246 seconds) |
| 03:53:03 | * | nimnoob joined #nim |
| 04:00:34 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:01:49 | * | boydgreenfield joined #nim |
| 04:05:35 | * | gmpreussner quit (Quit: Konversation terminated!) |
| 04:09:06 | * | flaviu quit (Ping timeout: 244 seconds) |
| 04:13:59 | boydgreenfield | flaviu/Araq/et al.: Ok, please feel free to commend + discuss here and then I can compile and integrate changes. https://github.com/Araq/Nimrod/pull/1748 |
| 04:14:04 | boydgreenfield | *comment |
| 04:16:16 | * | nimnoob quit (Ping timeout: 246 seconds) |
| 04:29:26 | willwillson | Varriount|Mobile: did you ever get your macro to index object fields by index working? |
| 04:30:45 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:31:37 | Varriount|Mobile | willwillson: Not the way I wanted to. |
| 04:31:48 | willwillson | Varriount|Mobile: did you see my gist? |
| 04:31:57 | Varriount|Mobile | Brb, switching to desktop |
| 04:36:37 | Varriount_ | willwillson: Nope. |
| 04:36:43 | * | Varriount_ is now known as Varriount |
| 04:36:58 | willwillson | Varriount: https://gist.github.com/cowboy-coders/1f3a6fbace89c4a2cf66 |
| 04:37:05 | willwillson | not sure if it is any good :D |
| 04:39:59 | Varriount | willwillson: Wow, that's impressive. |
| 04:40:35 | Varriount | I still like parts of it should be simpler (as in, the runtime engine and api should support it better) |
| 04:40:45 | Varriount | *still feel like |
| 04:41:29 | willwillson | yeah, I was hacking for a while on that one ;-) |
| 04:42:30 | Varriount | willwillson: The fact that you have to instantiate the type is particularly... unsatisfactory. |
| 04:42:58 | willwillson | Varriount: yeah I saw you made an issue for that one: have an iterator for the typedesc |
| 04:43:24 | Varriount | willwillson: Yes. I think it would simplify things |
| 04:43:51 | * | dts|pokeball quit (Read error: Connection reset by peer) |
| 04:44:50 | * | dts|pokeball joined #nim |
| 04:48:31 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 04:51:41 | * | gokr quit (Read error: Connection reset by peer) |
| 04:53:14 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 04:54:15 | * | vendethiel joined #nim |
| 05:08:39 | * | boydgreenfield joined #nim |
| 05:13:05 | dts|pokeball | does nim have a standard argument parser? |
| 05:13:32 | ldlework | dts|pokeball: you have the docs bookmarked at this point right? |
| 05:13:34 | * | willwillson quit (Ping timeout: 245 seconds) |
| 05:13:42 | dts|pokeball | i should |
| 05:13:49 | dts|pokeball | but im in a bad habit :/ |
| 05:13:51 | dts|pokeball | to the docs! |
| 05:15:51 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 05:19:46 | * | vendethiel joined #nim |
| 05:43:02 | * | dts|pokeball quit (Read error: Connection reset by peer) |
| 05:44:03 | * | dts|pokeball joined #nim |
| 05:48:28 | * | jasondotstar quit (Ping timeout: 258 seconds) |
| 05:49:47 | * | jasondotstar joined #nim |
| 05:52:06 | * | khmm joined #nim |
| 05:52:18 | * | pwernersbach quit (Quit: Leaving.) |
| 06:05:31 | * | quasinoxen quit (Ping timeout: 255 seconds) |
| 06:05:57 | * | irrequietus joined #nim |
| 06:06:24 | dts|pokeball | so im using parseopt2, do i need initOpParser if i use getopt? |
| 06:06:54 | * | quasinoxen joined #nim |
| 06:17:59 | * | irrequietus quit () |
| 06:54:53 | * | dts|pokeball quit (Read error: Connection reset by peer) |
| 06:55:20 | * | dts|pokeball joined #nim |
| 07:02:16 | * | nande_ quit (Remote host closed the connection) |
| 07:09:28 | * | bjz joined #nim |
| 07:18:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:42:55 | * | gour joined #nim |
| 08:06:03 | ldlework | hmm |
| 08:06:11 | ldlework | its annoying that when you alias a type |
| 08:06:20 | ldlework | you lose all procs for that type |
| 08:07:02 | * | Nimbus joined #nim |
| 08:07:27 | ldlework | nm |
| 08:07:35 | dts|pokeball | ,eval echo("Hello, world!") |
| 08:07:43 | Nimbus | dts|pokeball: Hello, world! |
| 08:08:00 | dts|pokeball | awesome |
| 08:10:02 | * | Nimbus quit (Remote host closed the connection) |
| 08:17:43 | * | Trustable joined #nim |
| 08:18:36 | dts|pokeball | https://github.com/DTSCode/Nimbus |
| 08:21:05 | * | gokr joined #nim |
| 08:24:20 | * | Varriount_ joined #nim |
| 08:27:17 | * | Varriount quit (Ping timeout: 240 seconds) |
| 08:32:32 | ldlework | what is this crap: Error: invalid argument for 'high' |
| 08:32:53 | ldlework | I have a high defined for my ref type |
| 08:37:19 | * | yglukhov joined #nim |
| 08:45:32 | * | yglukhov_ joined #nim |
| 08:45:33 | * | yglukhov quit (Read error: Connection reset by peer) |
| 08:45:43 | * | Hexagon quit (Ping timeout: 255 seconds) |
| 08:50:54 | Araq | ldlework: The following builtin procs cannot be overloaded for reasons of implementation |
| 08:50:56 | Araq | simplicity (they require specialized semantic checking):: |
| 08:50:57 | Araq | declared, defined, definedInScope, compiles, low, high, sizeOf, |
| 08:50:59 | Araq | is, of, shallowCopy, getAst, astToStr, spawn, procCall |
| 08:51:10 | Araq | (from the manual) |
| 08:59:02 | Araq | though ... nowadays we could make it work for 'low' and 'high' ... |
| 09:20:03 | * | bjz_ joined #nim |
| 09:20:06 | * | bjz quit (Read error: Connection reset by peer) |
| 09:30:20 | * | Jesin quit (Quit: Leaving) |
| 09:39:20 | ldlework | well |
| 09:39:23 | ldlework | it let me overload them |
| 10:17:04 | Araq | well the manual goes on on why that is |
| 10:17:30 | Araq | (there is also a serious typo in the following section) |
| 10:43:57 | ldlework | Is there an identity function? |
| 10:44:05 | ldlework | like telling whether you have the same reference? |
| 10:45:21 | Araq | system.== ? |
| 10:51:09 | Araq | bah ... (maxCaptures+1) * 3 |
| 10:51:22 | * | Araq wants strongSpaces |
| 11:18:43 | * | z1y quit (Ping timeout: 250 seconds) |
| 11:27:24 | * | dyu quit (Quit: Leaving) |
| 11:32:49 | * | Jesin joined #nim |
| 11:34:44 | * | bjz_ quit (Read error: Connection reset by peer) |
| 11:35:02 | * | bjz joined #nim |
| 11:35:23 | * | flaviu joined #nim |
| 12:00:19 | * | flaviu quit (Ping timeout: 272 seconds) |
| 12:00:30 | * | perturbation joined #nim |
| 12:07:22 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 12:08:13 | * | johnsoft joined #nim |
| 12:30:01 | * | saml_ joined #nim |
| 12:39:41 | * | z1y joined #nim |
| 12:39:53 | gokr | ldlework: We discussed "identity" the other day - and since Nim has value types, where one kind of value is a ref - then for ref types an "identity check" turns into the base == implementation in system - namely "do these values have the same bits?". |
| 12:40:08 | gokr | AFAIK |
| 12:40:52 | gokr | Personally I would like to have some alias perhaps - like === that we could use when we mean "system.==" and not the implemented == in our object. |
| 12:53:14 | * | z1y left #nim (#nim) |
| 12:59:07 | Araq | gokr: template `===`(a, b): expr = system.`==`(a, b) |
| 12:59:29 | Araq | as usual, the question of "does this really belong into system.nim" arises |
| 12:59:32 | gokr | Yeah, I think you proposed it |
| 13:00:00 | Araq | I'm only saying that usually Nim gives you what you want |
| 13:00:33 | gokr | Well... I would say it does, since... overriding == will be relatively normal. |
| 13:00:44 | gokr | ("belong" I mean) |
| 13:01:29 | perturbation | one I thing I (just) learned in Ruby is that there are like 4 different equality operators |
| 13:01:29 | gokr | Yes, but I want such a "fundamental" thing to be in stdlib. |
| 13:01:51 | perturbation | #eqls?, #==, #===, and #equal? |
| 13:02:03 | Araq | well you think overriding == for ref object is normal, but I never used it in my entire life |
| 13:02:33 | Araq | it's easy enough to split the "key" part from it and have that in a tuple and use the Table as is |
| 13:02:33 | EXetoC | a[] == b[]? |
| 13:02:40 | perturbation | which seems messed up, but they are intentionally different so that they can be overridden for different purposes (hashes, case statements, 'normal', and pointer) |
| 13:03:11 | EXetoC | I think it's a good idea to only consider the basic type unless necessary. var parameters rather than ref parameters for example |
| 13:03:14 | gokr | Araq: In my Pharo 3.0 image with some stuff in it - 200 implementors of #= |
| 13:03:18 | EXetoC | maybe some syntactical can be justified in certain cases |
| 13:03:52 | * | quasinoxen quit (Ping timeout: 256 seconds) |
| 13:04:10 | gokr | Araq: Granted, some of the usecases disappear with static typing. |
| 13:04:21 | EXetoC | in the case of foo[].bar() maybe? |
| 13:04:43 | Araq | I really don't like === vs ==. It's messy and reminds of JavaScript. |
| 13:05:28 | gokr | But you think "if system.`==`(x,b):" doesn't look messy? |
| 13:06:12 | Araq | it kind of does, but as I said, I never override == for ref object and so I don't need to write system.`==` either |
| 13:06:29 | gokr | But perhaps you don't use much objects either ;) |
| 13:07:38 | Araq | yeah, perhaps. |
| 13:08:12 | Araq | like the guy on the forum who has lots of different "shapes" and wants them to work across DLL boundaries |
| 13:08:32 | Araq | I don't have lots of different shapes to begin with ;-) |
| 13:08:57 | perturbation | "This isn't even my final form!" |
| 13:10:29 | EXetoC | what does == for refs do again? |
| 13:12:04 | perturbation | pointer equality, I thought |
| 13:12:18 | Araq | and I note that the hardware supports "array of pixels" and "array of triangles" and not much else. IMO it's very telling that efficiency comes from focussing on 1 shape. |
| 13:14:42 | EXetoC | Araq: is that the case? pointer equality |
| 13:14:55 | Araq | EXetoC: yes |
| 13:16:21 | EXetoC | gokr: is "proc `==`(a, b: Foo): bool" not what you want then? in other words, a[] == b[] at the call site |
| 13:16:28 | EXetoC | don't like that? |
| 13:17:23 | gokr | First of all, there is a slight "gotcha" in the fact that I have to implement == in leaf "classes" in order to override it (superclasses will not work). |
| 13:18:16 | gokr | Secondly, I would like to write "a == b" for equality testing regular "ref objects" (Nim then uses the one the ref object), but I would also like to write say "a === b" meaning "are these two refs identical?" |
| 13:18:32 | * | gour quit (Disconnected by services) |
| 13:18:32 | * | gour_ joined #nim |
| 13:18:48 | gokr | In other words, I would like to be able to call the == that is in system, without resorting to "system.`==`(a,b)" |
| 13:19:00 | gokr | In order to do an identity check, and not an equals check. |
| 13:20:01 | EXetoC | so that's a yes then, you don't like a[] == b[]? |
| 13:21:02 | gokr | Not really, no. And... then you are calling == on the... value type, and not on the ref type. |
| 13:22:10 | * | gour_ is now known as gour |
| 13:22:17 | gokr | I fiddled with that, and... right now I don't remember - but... there was some issue there. |
| 13:22:21 | EXetoC | I don't know why 'ref' should be of relevance |
| 13:22:44 | * | nimnoob joined #nim |
| 13:24:35 | gokr | I gotta run, and right now I don't recall exactly what the issue was. |
| 13:24:45 | EXetoC | but ok maybe it's more common to compare the actual contents. in which case maybe it would be nice to have some syntactic sugar, and then something like 'is' for comparing the pointers, but it might be too late for that |
| 13:29:08 | * | perturbation quit (Quit: Leaving) |
| 13:33:56 | Araq | er... usually people use 'ref object' to get *reference* semantics where the identity usually really is the pointer value ... |
| 13:34:13 | EXetoC | implicit dereferencing in other words, similar to how it works with 'this' in C++ and D |
| 13:34:52 | Araq | C++ and D compare pointers by their pointer values too, believe it or not |
| 13:37:42 | * | zebra111 joined #nim |
| 13:38:11 | EXetoC | ok I forgot about -> |
| 13:42:13 | EXetoC | and D just has '.'. are you opposed to implicit dereferencing? or whatever you want to call it |
| 13:42:28 | EXetoC | but D doesn't have a qualifier for objects allocated on the GC heap |
| 13:43:35 | EXetoC | and you might need actual member functions for it to be feasible |
| 13:43:38 | Araq | sometimes it's like you never programmed in Nim |
| 13:44:00 | Araq | obj.field instead of obj[].field is used everywhere in Nim |
| 13:44:18 | EXetoC | huh |
| 13:45:25 | EXetoC | yes but it doesn't dereference implicitly |
| 13:46:50 | EXetoC | had it been necessary in order for it compile that is (when said proc takes a var rather than a pointer or reference) |
| 13:48:55 | Araq | auto-deref in more contexts is still on my todo |
| 13:49:09 | Araq | but it won't turn a==b into a[]==b[] |
| 13:49:40 | Araq | instead the current plan is that only obj.foo(a, b) can be rewritten to obj[].foo(a, b) |
| 13:49:54 | Araq | this looks like a sweet compromise |
| 13:50:03 | Araq | but we'll see how it works out in practice |
| 13:50:19 | * | BitPuffin joined #nim |
| 13:54:17 | EXetoC | and when a proc that takes a plain object is introduced? though that seems rare |
| 13:55:27 | Araq | then that's preferred |
| 13:55:33 | EXetoC | and ideally you'd have unit tests that'd catch any such mistakes |
| 13:59:12 | Araq | why? |
| 13:59:31 | Araq | you think that the better matching proc necessarily leads to a bug then |
| 13:59:42 | Araq | but on the contrary |
| 14:00:07 | Araq | the overloaded proc should ensure "similar enough" semantics |
| 14:00:15 | Araq | otherwise it should have got a different name |
| 14:00:25 | * | nimnoob quit (Ping timeout: 246 seconds) |
| 14:00:45 | EXetoC | yes well I did say it seemed rare |
| 14:05:43 | * | dyu joined #nim |
| 14:08:05 | * | mbenadda joined #nim |
| 14:14:30 | Araq | hi mbenadda |
| 14:14:55 | mbenadda | hi Araq |
| 14:15:08 | * | nimnoob joined #nim |
| 15:00:12 | * | zebra111 quit (Read error: Connection reset by peer) |
| 15:38:11 | * | yglukhov_ quit (Ping timeout: 272 seconds) |
| 15:51:28 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 15:54:39 | * | darkf quit (Ping timeout: 272 seconds) |
| 16:20:19 | * | khmm quit (Ping timeout: 250 seconds) |
| 16:53:54 | * | Matthias247 joined #nim |
| 16:57:47 | * | yglukhov_ joined #nim |
| 16:59:34 | * | quasinoxen joined #nim |
| 17:21:56 | * | saml_ quit (Ping timeout: 250 seconds) |
| 17:28:17 | * | gour__ joined #nim |
| 17:28:17 | * | gour quit (Disconnected by services) |
| 17:34:03 | * | gour__ is now known as gour |
| 17:34:13 | * | mbenadda quit (Quit: Be back later ...) |
| 17:34:30 | * | nimnoob quit (Quit: Page closed) |
| 17:35:27 | * | nimnoob joined #nim |
| 17:36:41 | ldlework | just add "is" srsly |
| 17:37:57 | ldlework | no brainer |
| 17:39:05 | * | Hexagon joined #nim |
| 17:40:26 | * | Hexagon quit (Client Quit) |
| 17:42:41 | * | zebra111 joined #nim |
| 17:44:09 | gokr | ldlework: We already have "is" for type equiv at compile time |
| 17:45:10 | ldlework | unfortunate |
| 17:46:26 | ldlework | I think that == should compare reference identity honestly as araq says a[] == b[] is annoying but it is explicit |
| 17:47:11 | ldlework | It keeps reference and value semantics more segregated |
| 17:47:39 | nimnoob | but those semantics are less segregated in other regards |
| 17:47:59 | ldlework | when I look at some expression, I don't want to have to look at the definition of the values to understand whether the expression is dealing with reference semantics or value semantics |
| 17:48:12 | * | flaviu joined #nim |
| 17:48:35 | ldlework | in the case that the names are references but we're operating with value semantics, that each reference is marked [] is suppppppper explicit and informative |
| 17:48:41 | ldlework | I think this is really good |
| 17:48:54 | nimnoob | which of these is a reference and which of these is a value: person.name and person.name |
| 17:49:20 | ldlework | But in that case the propositional arguments are name and name |
| 17:49:22 | nimnoob | should it be person[].name? |
| 17:49:24 | ldlework | no |
| 17:50:23 | ldlework | do you understand what I mean that the expressions are revolving around `name` and `name`? |
| 17:50:42 | ldlework | If person is a reference or value is insignificant to understanding the expression |
| 17:51:01 | ldlework | whether person is a reference or value, the expression semantics are the same because you'd be working with the same `name` in both cases |
| 17:51:24 | nimnoob | i understand |
| 17:52:38 | nimnoob | a[] == b[] is certainly explicit |
| 17:52:42 | ldlework | It would only matter if name is a reference or not, in which case [] kicks in |
| 17:53:28 | ldlework | and I feel like if you want sugar for your dereferencing equality, *thats* when you should implement === for your type |
| 17:54:08 | ldlework | You can remember the === semantic by imaginging that since it is longer that it "reaches into" the refernce for comparison |
| 17:54:13 | ldlework | Araq: gokr thoughts? |
| 18:04:40 | * | brson joined #nim |
| 18:14:12 | gokr | I am too Smalltalk biased. I don't think I would like [] all over the place though. |
| 18:14:52 | gokr | But one thing I do think - is to have separate "operators" for equality and identity. |
| 18:15:22 | ldlework | gokr: but identity is reference equality |
| 18:15:42 | gokr | Yes, but since refs have these "smarts" in them - then it gets blurred. |
| 18:15:52 | ldlework | what smarts? |
| 18:16:55 | ldlework | like field access and being able to call procs on the ref? |
| 18:17:02 | gokr | Well, "a == b" may use system.== but it may also use the == in the ref object type. Perhaps not a good example, but AFAIK .... yes. |
| 18:17:28 | gokr | Ok, I gotta go play badminton. |
| 18:17:32 | ldlework | :P |
| 18:17:35 | ldlework | see ya |
| 18:17:38 | gokr | ciao :) |
| 18:29:58 | * | Jesin quit (Quit: Leaving) |
| 18:34:57 | * | mbenadda joined #nim |
| 18:39:38 | * | mbenadda quit (Ping timeout: 265 seconds) |
| 18:47:34 | * | kmcguire joined #nim |
| 18:47:53 | ldlework | hi kmcguire |
| 18:48:00 | kmcguire | hey ldlework |
| 18:48:11 | * | dyu quit (Quit: Leaving) |
| 18:49:12 | ldlework | Does anyone have any informaiton on Nim benchmarks? |
| 18:51:23 | ldlework | kmcguire: if you end up doing your own benchmarks make sure to share your results! |
| 18:51:57 | kmcguire | yes i will - was just curious about nimrod but did not have the time but if it turned out to have good performance i was going to try squeezing it into some of my projects |
| 18:52:26 | * | kniteli joined #nim |
| 18:54:52 | * | milosn quit (Ping timeout: 245 seconds) |
| 18:59:53 | Araq | kmcguire: there are several benchmarks showing good performance but I don't have a link ready |
| 18:59:56 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:00:33 | kmcguire | Araq: ok, one in particular is maybe n-body. Its pretty simple. |
| 19:00:44 | kmcguire | At least one I can understand, lol. |
| 19:01:01 | kmcguire | I guess i could try to write one. |
| 19:19:57 | * | AMorpork is now known as BuyingMorpork |
| 19:20:23 | * | Mat4 joined #nim |
| 19:20:30 | Mat4 | hi all |
| 19:26:09 | * | yeye123 joined #nim |
| 19:29:27 | flaviu | " Compile and run with: nim c -r example.nim View at: localhost:5000" Doesn't look too good. Perhaps a comment on the last line saying "# served on localhost:5000" would be better |
| 19:33:15 | Araq | flaviu: let's see what dom96 thinks, I added this to his suggestion |
| 19:33:33 | Araq | btw I do use the back-links to the TOC ... |
| 19:33:48 | Araq | and I copied that feature from python's docutils |
| 19:35:04 | ldlework | I feel like each relevant token in the example snippets should be links to the relevant docs |
| 19:35:34 | flaviu | ldlework: very gracious of you to volunteer to implement that! ;) |
| 19:35:44 | ldlework | flaviu: It doesn't have to be automated |
| 19:38:16 | * | nimnoob quit (Ping timeout: 256 seconds) |
| 19:40:01 | ldlework | Also |
| 19:40:15 | ldlework | The text accompanying the snippets should just be comments in the snippet |
| 19:40:47 | ldlework | not the titles, but the descriptive text |
| 19:40:55 | ldlework | "Nim is the only language..." |
| 19:41:02 | ldlework | "View at localhost:..." |
| 19:42:12 | Araq | ldlework: I disagree. The text "Nim is the only language ..." is not a comment. |
| 19:42:36 | ldlework | Araq: not in the sense that we're going to put that code into a library and distribute it no |
| 19:42:49 | ldlework | But for the aesthetics of this feature of the website, I think it would look far better |
| 19:43:03 | Mat4 | Araq: Can you please give me an example again for the usage of computedGoto ? |
| 19:43:17 | Araq | while true: |
| 19:43:18 | ldlework | Honestly, I think the entire block of text on the disjoint prover is too much and too leading |
| 19:43:24 | flaviu | I'd just like to point out that people *hate* reading. |
| 19:43:26 | Araq | {.computedGoto.} |
| 19:43:30 | Araq | case instruction |
| 19:43:36 | Araq | of iAdd: ... |
| 19:43:40 | Mat4 | ok thanks |
| 19:43:44 | flaviu | fewer words is always better than more words. |
| 19:44:01 | Araq | I already shortened the description |
| 19:44:27 | Araq | but if you cannot even read the answer to the question "why should I be excited?" maybe you should leave the site immediately |
| 19:44:42 | Araq | I mean seriously. |
| 19:44:42 | ldlework | "Nim uses automated proofs to perform a disjoint check for parellel code. Disjoint data means data races are impossible." |
| 19:44:48 | ldlework | Araq: no I mean seriously |
| 19:44:59 | ldlework | I'm making minor suggestions and you should take them as such |
| 19:46:19 | ldlework | I guess I just don't like the arrogant tone of the line, or how the "View at localhost" looks squished under the example. |
| 19:46:42 | ldlework | I tried to unify my problems with those two small things by suggesting to put them as comments in the source |
| 19:46:46 | * | zebra111 quit (Ping timeout: 255 seconds) |
| 19:46:57 | ldlework | (encouraging shortening the parellel description (which removes the arrgoant tone)) |
| 19:48:12 | Araq | what's wrong with the arrogant tone? isn't it kind of the point of the website to sell the lang to newcomers? |
| 19:48:29 | ldlework | You don't need to sell what people already want. |
| 19:48:40 | ldlework | Inform them of what it is, they'll decide if they want to buy it. |
| 19:48:49 | ldlework | How do you build the site sources to test local changes? |
| 19:48:57 | Araq | koch website |
| 19:50:21 | ldlework | hmm I don't seem to have a website command |
| 19:50:24 | ldlework | probably need to update |
| 19:50:29 | Araq | yup |
| 19:52:40 | Araq | can we close https://github.com/Araq/Nimrod/issues/652 now? |
| 19:52:55 | Araq | I think we'd have noticed if Nim is broken on Ubuntu, right? |
| 19:54:33 | flaviu | Araq: Do you understand what the problem is? |
| 19:55:00 | Araq | flaviu: yeah but --passL already appends |
| 19:55:07 | Araq | so it ends up being fine |
| 19:55:19 | * | rpag joined #nim |
| 19:56:43 | Araq | not to mention that the real issue is that some Linux beard decided it's fine to break stuff because of reasons. Amateurs. |
| 20:00:03 | flaviu | "Linux beard": Is that some new beard style? :P |
| 20:00:16 | dts|pokeball | hey guys... ive gone through the whole compiler docs, but i cant figure out how to specify what compiler i want nim to use. the closest i could find is the cross compilation thing |
| 20:00:25 | dts|pokeball | flaviu, yes. it looks like a penguin |
| 20:02:44 | Araq | flaviu: I can find neither #8c94a2 nor #333333 in my CSS |
| 20:02:59 | Araq | so what contrast are you talking about? |
| 20:03:32 | flaviu | Araq: Because they are not in the CSS: The foreground is rgba(0, 0, 0, .8), which depends on all the colors underneath it. |
| 20:03:36 | Araq | dts|pokeball: it's even the last entry in the FAQ |
| 20:03:37 | * | repax joined #nim |
| 20:03:54 | flaviu | The background is similar, it uses transparency too. |
| 20:04:10 | Araq | well please make a PR that fixes it |
| 20:04:22 | * | gour quit (Quit: WeeChat 1.0) |
| 20:06:16 | * | nimnoob joined #nim |
| 20:10:22 | Araq | ugh a few more of these trivial bugfixes and I'll fix lambda lifting bugs instead |
| 20:10:32 | * | Araq needs a challenge |
| 20:10:58 | * | nimnoob quit (Ping timeout: 258 seconds) |
| 20:11:30 | flaviu | Sorry, I have absolutely no desire to touch that css. |
| 20:11:31 | flaviu | But filwit isn't as terrible at css as I initially assumed: The css is bad because it's machine-generated, not because he sucks. |
| 20:12:11 | flaviu | or so I hope, it looks very similar to sass output. |
| 20:13:47 | ldlework | Araq: idetools, forward type decls, etc :) |
| 20:15:30 | * | dts|pokeball quit (Read error: Connection reset by peer) |
| 20:16:18 | * | dts|pokeball joined #nim |
| 20:16:36 | * | brson quit (Quit: leaving) |
| 20:16:50 | * | brson joined #nim |
| 20:16:56 | * | BuyingMorpork is now known as AMorpork |
| 20:17:21 | Araq | yeah I guess I will fix idetools instead |
| 20:18:57 | * | brson quit (Client Quit) |
| 20:19:12 | * | brson joined #nim |
| 20:22:31 | wan_ | kmcguire, ldlwork: I translated nbody and fastaredux a couple of weeks ago https://gist.github.com/idlewan/ab53b761ab1522251682 |
| 20:23:09 | reactormonk | dom96, you sure you want .nimble as dotfile? I think it shouldn't be a dotfile. |
| 20:24:00 | * | mbenadda joined #nim |
| 20:24:27 | ldlework | We should probaby refactor the site to use SASL or something... |
| 20:25:09 | wan_ | I'm not sure you meant SASL |
| 20:25:36 | * | brson quit (Ping timeout: 244 seconds) |
| 20:25:38 | * | wan_ is now known as wan |
| 20:25:43 | Araq | don't make install some crappy Ruby based hipster CSS alternative |
| 20:26:21 | wan | I guess you would have the same reaction with node libs? |
| 20:26:43 | wan | A CSS preprocessor is pretty standard for web development nowadays |
| 20:27:37 | wan | and reinventing the wheel in Nim wouldn't be very productive |
| 20:27:59 | Araq | I already have a Nim based templating language, I can use that for CSS too. |
| 20:28:06 | ldlework | oh god |
| 20:28:11 | * | mbenadda quit (Ping timeout: 244 seconds) |
| 20:28:12 | ldlework | SASS != templating language |
| 20:28:50 | Araq | there is no "re-inventing the wheel" when you already have all the tools already |
| 20:29:58 | EXetoC | it has variables, mixins and so on |
| 20:31:02 | flaviu | ldlework: Sorry, I'm not really sure what the difference between sass and scss is :P |
| 20:31:12 | wan | I use Stylus all the time, you wouldn't achieve the same clean file.styl with a Nim templating language |
| 20:31:45 | ldlework | flaviu: SCSS is preferred |
| 20:32:56 | flaviu | Araq: http://libsass.org/ |
| 20:32:59 | Araq | ldlework: it's a preprocessor according to its own documentation ... |
| 20:33:31 | ldlework | Araq: preprocessors are a superset of templating |
| 20:34:49 | flaviu | Araq: My problem is that nim tempting looks ugly. |
| 20:34:53 | flaviu | *templateing |
| 20:36:04 | Araq | my problem with "libsass" is its very existance |
| 20:36:14 | * | brson joined #nim |
| 20:36:14 | ldlework | Not to mention nim templating is compile time only |
| 20:37:38 | flaviu | Araq: Please elaborate |
| 20:37:46 | ldlework | Is there a reason we don't use a javascript library like jQuery either? |
| 20:38:01 | ldlework | adding and removing classes and other basic things are a complete chore without them |
| 20:38:15 | ldlework | oh there's classList now |
| 20:38:17 | ldlework | nm |
| 20:44:56 | EXetoC | Araq: not the necessity then? because of lack of re-use constructs in CSS |
| 20:47:49 | ldlework | If I have permission to introduce jQuery I can be convinced to refactor the snippet system |
| 20:47:57 | ldlework | make it so we don't have to hand craft each one |
| 20:49:07 | EXetoC | hand craft what? |
| 20:49:42 | Araq | ldlework: no jQuery. |
| 20:49:50 | ldlework | EXetoC: each snippet |
| 20:49:59 | ldlework | Araq: is there any reason other than arbitraryness |
| 20:50:26 | EXetoC | the ones on the index? |
| 20:50:34 | ldlework | EXetoC: yeah |
| 20:50:40 | Araq | well hrm I don't want to learn jQuery when you disappear |
| 20:50:40 | EXetoC | aren't those generated? |
| 20:50:45 | ldlework | EXetoC: no |
| 20:50:52 | EXetoC | well we have tools for that, don't we? |
| 20:51:04 | ldlework | EXetoC: what are you talking about |
| 20:51:09 | Araq | yeah but filwit uses special styling |
| 20:51:18 | Araq | so I couldn't be bothered to automate it |
| 20:51:19 | ldlework | Araq: fine, I've been meaning to up my game with new DOM api's anyway I guess |
| 20:51:35 | ldlework | filwit? |
| 20:51:45 | Araq | the guy who created the website |
| 20:52:18 | * | boydgreenfield joined #nim |
| 20:52:31 | wan | for the ones interested in notjquerying: http://blog.garstasio.com/you-dont-need-jquery/ |
| 20:53:06 | flaviu | Araq: I'm not arguing that jquery should be used on the nim website (I don't really care), but it really isn't hard to use and makes many things much easier. |
| 20:53:32 | EXetoC | yeah, not too hard |
| 20:53:59 | Araq | I don't want jQuery, NewAwesomeCssThatDoesn'tEvenFixTheOriginalDesignMistakes, no Sphinx, no Ruby based makefile replacement, no awesome autoconf replacement. I write my own tools because I can fix them and it's more fun. |
| 20:54:32 | Araq | I have a serious NIH syndrome and without it, Nim even wouldn't exist in the first place |
| 20:54:51 | wan | and we all like you for it |
| 20:55:12 | repax | Something similar to libsass could be done in nim |
| 20:55:43 | flaviu | libsass is in C, in case it's not obvious. |
| 20:55:44 | * | repax is looking at someone else |
| 20:57:21 | repax | actively developed, so perhaps just interface with it then? |
| 20:57:53 | flaviu | I was going to create a wrapper, but then I realized I was just yak shaving |
| 20:58:45 | flaviu | perhaps if someone else had the time, they could wrap it. |
| 21:00:07 | ldlework | Why is yak shaving a bad thing? |
| 21:00:30 | ldlework | Just trying to add a new snippet is a fucking nightmare |
| 21:00:48 | ldlework | Ignoring the yaks is a maintainence nightmare |
| 21:01:18 | ldlework | The website is going to be a thing no one wants to touch in approx 6 months. |
| 21:01:19 | Araq | ldlework: well I don't have more snippets |
| 21:01:31 | ldlework | Because no one wants to fix Araq's new saas replacement |
| 21:01:35 | ldlework | or whatever |
| 21:01:38 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 21:01:42 | Araq | er what? |
| 21:01:50 | Araq | already nobody wants to touch it |
| 21:01:56 | ldlework | Araq: yeah that's the problem |
| 21:02:02 | ldlework | And NIH is just going to make it worse |
| 21:03:09 | * | nimnoob joined #nim |
| 21:03:16 | Araq | can't see how. it's not like I dream up new ways of doing things. I simply use the things we already have and which work. |
| 21:03:18 | flaviu | ldlework: No, I was going to wrap it for another project, but I then realized that the time taken to wrap would be too long, and that just plain CSS was easier. |
| 21:03:33 | EXetoC | it's big? |
| 21:03:34 | ldlework | flaviu: ah |
| 21:03:57 | ldlework | Araq: the things we already have are jQuery, SCSS, Sphinx and so on |
| 21:04:08 | EXetoC | flaviu: what do you think is ugly about templates? |
| 21:04:39 | * | nimnoob quit (Remote host closed the connection) |
| 21:04:59 | repax | as for NIH: most of libsass is just a parser and a lexer. If nim had some internal representation similar to what json is for js then only a generator would be needed |
| 21:05:16 | Araq | ldlework: really? these things all have no standard and in 10 years half of them will have been replaced by "better tools" |
| 21:05:54 | Araq | with a bit of luck by tools written in Nim :P |
| 21:06:17 | ldlework | Araq: jQuery has been around for 8 years |
| 21:06:42 | flaviu | EXetoC: Look at http://jinja.pocoo.org/docs/dev/, and then look at http://nim-lang.org/filters.html. It's clear that jinja2 is specifically designed for it's primary use and is generally much nicer to use. |
| 21:06:58 | flaviu | Araq: Yeah, jquery isn't going anywhere. something like 90% of websites use it. |
| 21:07:01 | ldlework | flaviu +1 |
| 21:07:07 | ldlework | flaviu: +1 again |
| 21:07:31 | Araq | flaviu: I disagree |
| 21:07:43 | Araq | filters kick ass |
| 21:07:57 | EXetoC | flaviu: you mean more verbose, when "inheriting" and so on |
| 21:08:01 | Araq | and if you don't like them, you can use onionhammer1's instead anyway |
| 21:08:26 | EXetoC | someone could just create a good userland templating engine, right? |
| 21:08:34 | Araq | on the contrary |
| 21:08:44 | flaviu | Araq: onionhammer's are not really comparable with jinja2 in terms of awesomeness at this point. |
| 21:08:48 | Araq | {% endfor %} is a pita, and #end for is much easier to type |
| 21:08:54 | EXetoC | a la vibe.d's render template. just pass in some aliases |
| 21:09:10 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:09:11 | EXetoC | variables |
| 21:10:11 | EXetoC | Araq: other template engines has a couple more features though |
| 21:10:29 | flaviu | Araq: but `{% for user in users %}<li>{{user}}</li>{% endfor %}` is even better than #end. |
| 21:10:41 | * | jasondotstar quit (Ping timeout: 272 seconds) |
| 21:11:39 | wan | Araq: no #end in jade is much better |
| 21:12:15 | Araq | I can see no arguments here. All I see is the typical "invented somewhere else" syndrome. |
| 21:12:43 | Araq | which is a thing too and usually reads like "github uses markdown, so markdown is much better than RST" |
| 21:12:59 | * | jasondotstar joined #nim |
| 21:13:00 | wan | well, I see the "use tools that already work well enough" argument |
| 21:13:03 | EXetoC | Araq: why is it a language construct? just wondering |
| 21:13:41 | Araq | wan: but they don't. JavaScript doesn't work and putting libs on top doesn't fix it, replacing JS does fix it. |
| 21:13:53 | flaviu | Araq: You are one person. There is no way that you can create things with the same polish as hundreds of other people combined. |
| 21:14:09 | Araq | flaviu: but it's not necessary either. |
| 21:15:55 | flaviu | Huh? You may prefer to use tools that you've invented yourself, but most others prefer to use the best tools available or those they've created themselves. |
| 21:16:26 | Araq | yes, but at the end of the day, I do all the work anyway. |
| 21:16:36 | * | BlaXpirit joined #nim |
| 21:16:36 | Araq | pissing off the most important person is not a wise move. |
| 21:17:05 | ldlework | Araq: if you're saying that your equivocation of something like Jinja2 to Nim templates is valid and you are going to ignore that they are obviously not equivalent and say you see no argument |
| 21:17:08 | ldlework | that's just being unreasonable |
| 21:17:34 | Araq | Nim templates -- compile to kickass code and let you use all your nim goodies. |
| 21:17:46 | Araq | Jinja2 -- just some random thingie. |
| 21:17:53 | wan | Araq: Anyone used to highly specialized indent-based tools like Jade and Stylus finds it a pain to go back to ugly CSS. Some stuff do work, they don't fix CSS's inherent problems but they fix some others. Same for a lot of domains, good tools might not be perfect, but they still do their task |
| 21:17:54 | Araq | you're right, there is no comparison here. |
| 21:18:14 | ldlework | There's nothing mututally exclusive with Nim templates compiling to kickass code, letting you use your nim goodings *AND* being a competent templating language |
| 21:18:33 | flaviu | Araq: Please at least use what you're bashing briefly before bashing it. |
| 21:18:47 | ldlework | Yeah jinja2 is an absolute joy |
| 21:20:01 | ldlework | Also limiting the amount of control constructs in a templating language is actually a benefit |
| 21:20:12 | Araq | omg |
| 21:20:16 | ldlework | That jinja2 exposes basic python constructs but not the entire language is why jinja2 is better than PHP |
| 21:20:20 | Araq | not this again |
| 21:21:01 | * | boydgreenfield joined #nim |
| 21:21:02 | repax | I'm not sure I understand why such a limitation would be a feature |
| 21:21:14 | wan | I guess this argument is DSLs or One Language To Rule Them All? |
| 21:21:35 | * | Araq won't listen to any of this. |
| 21:21:59 | repax | Well, an all-purpose language doesn't have to be a One-To-Rule-Them-All |
| 21:22:16 | repax | It only has to be an all-purpose language |
| 21:23:18 | ldlework | Also Nim templates are compile time, so they are largely useless anyway |
| 21:23:19 | flaviu | I don't agree that limiting the template should be seen as a feature, but I do think that the limits are at all a problem in practice. My experience with jinja2 is limited, but I never ran into any problems with the limitations. |
| 21:24:46 | ldlework | flaviu: why is PHP bad in the general sense |
| 21:24:46 | flaviu | ldlework: "largely useless" - it really depends on your mental model. There is no reason not to recompile your program with your templates. |
| 21:25:03 | ldlework | flaviu: excempt that my templates are rendered at runtime, with runtime data |
| 21:25:38 | flaviu | ldlework: Lots of terribly named and inconsistent APIs. Also, terrible performance and hebrew error codes. |
| 21:26:58 | flaviu | I don't like the idea of creating templates at runtime. There isn't any reason to have to do so that I can see. |
| 21:30:38 | * | Nimbus joined #nim |
| 21:30:40 | * | Matthias247 joined #nim |
| 21:30:56 | * | Nimbus quit (Remote host closed the connection) |
| 21:32:35 | * | yeye123 quit (Quit: Leaving) |
| 21:35:48 | EXetoC | ldlework: by compile time you mean that's when you define them? then yes, but you're defining a proc that can be passed run-time values |
| 21:35:59 | ldlework | EXetoC: ah |
| 21:37:10 | ldlework | Does Nim have a C compliant ABI? |
| 21:37:14 | EXetoC | just a normal proc in other words |
| 21:37:21 | dom96 | reactormonk: no? |
| 21:38:00 | EXetoC | Araq: was it easier to implement the templating system in the compiler or was that just what came to mind at the time? |
| 21:38:06 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:39:22 | flaviu | ldlework: Yes, {. cdecl .}. |
| 21:40:35 | Mat4 | does Nim have a 'constructor' identifier ? |
| 21:41:09 | EXetoC | identifier? no |
| 21:41:28 | EXetoC | what does that imply btw? |
| 21:41:59 | flaviu | https://github.com/Araq/Nimrod/issues/1693 |
| 21:42:05 | flaviu | Mat4: ^ |
| 21:45:12 | ldlework | I really hope that we eventually get a way to create ref literals with implicit new |
| 21:45:45 | flaviu | "implicit new"? |
| 21:45:58 | EXetoC | that is possible |
| 21:46:04 | EXetoC | let's see |
| 21:46:13 | ldlework | var fooRef = @Foo(x: 1, y: 2) |
| 21:46:15 | ldlework | something like that |
| 21:46:26 | ldlework | instead of defining a newFoo for everything |
| 21:46:37 | ldlework | or doing |
| 21:46:41 | ldlework | var fooRef = new Foo |
| 21:46:44 | EXetoC | and we'll still use ref aliases and such |
| 21:46:44 | dom96 | reactormonk: ".nimble files" refers to files such as "gtk2.nimble" and "jester.nimble" |
| 21:46:45 | ldlework | fooRef.x = 1 |
| 21:46:46 | ldlework | etc |
| 21:46:59 | flaviu | ldlework: Oh. I beat you to it! |
| 21:47:00 | flaviu | https://gist.github.com/flaviut/1ae1d7deac4c57d0a84c |
| 21:47:13 | EXetoC | why not just call new then? |
| 21:47:23 | ldlework | EXetoC: huh? |
| 21:47:42 | ldlework | oh nice, why didn't I think of generics |
| 21:47:44 | ldlework | :P |
| 21:47:50 | ldlework | but seriously, that should be syntax |
| 21:47:58 | * | Nimbus joined #nim |
| 21:48:00 | ldlework | (or standard macro or whatever) |
| 21:48:09 | flaviu | EXetoC: `box Foo( a: 1, b: "fas")` is better than `var myVal: ref Foo; new var; var.a = 1; var.b = "fas"` |
| 21:48:24 | ldlework | flaviu: by a million years |
| 21:48:26 | ldlework | thanks a bunch |
| 21:48:40 | EXetoC | RefType(...) |
| 21:48:50 | EXetoC | with implicit allocation |
| 21:48:56 | ldlework | I have problems deciding when to use "func arg", "func(arg)" and "arg.func" |
| 21:49:17 | flaviu | EXetoC: What if you only want to allocate it once or twice, or what if you want to allocate a pointer on the heap? |
| 21:49:40 | ldlework | Yeah I don't define ref types |
| 21:49:48 | ldlework | I just do "ref Foo" everywhere |
| 21:49:58 | ldlework | so this box helper is very nice |
| 21:50:15 | * | brson quit (Ping timeout: 258 seconds) |
| 21:50:21 | EXetoC | well it's a convention |
| 21:50:36 | ldlework | the language is still young :) |
| 21:50:46 | ldlework | though I imagine ref aliases will win out |
| 21:50:49 | EXetoC | (ref T)() works too |
| 21:51:01 | ldlework | that implicitly calls new? |
| 21:51:08 | EXetoC | yes, that too |
| 21:51:20 | ldlework | That's cool |
| 21:51:24 | ldlework | but really |
| 21:51:25 | EXetoC | that still leaves us with pointers though |
| 21:51:27 | ldlework | it should be syntax |
| 21:51:29 | ldlework | :D |
| 21:51:41 | flaviu | `box T(...)` has the potential to be much more flexible than `(ref T)(...)` |
| 21:51:43 | ldlework | I suggest @ since it goes along with @[] |
| 21:52:12 | * | Nimbus quit (Remote host closed the connection) |
| 21:52:19 | ldlework | and I sort of think of seq being a ref to an array with a bunch of methods defined in system.nim :) |
| 21:52:25 | EXetoC | flaviu: in what way? |
| 21:52:44 | ldlework | EXetoC: its a proc so you can do things, for one |
| 21:52:57 | ldlework | You could overload box for different types |
| 21:53:20 | flaviu | EXetoC: If it becomes possible to overload on type names, T(...) can be used as a constructor. |
| 21:53:31 | dom96 | ldlework: Why don't you just define your type as 'ref'? |
| 21:53:50 | flaviu | So box T(...) creates a T with a constructor and moves it onto the heap. |
| 21:54:32 | ldlework | dom96: Because I like having a single type name to work with |
| 21:55:03 | ldlework | Point rather than Point and PointObj, or PointRef and Point, etc |
| 21:55:13 | dom96 | Why do you need two? |
| 21:55:18 | dom96 | Just use ref everywhere? |
| 21:55:23 | ldlework | dom96: what does the ref refer to? |
| 21:55:37 | EXetoC | flaviu: syntactic sugar for allocation-agnostic construction might be added though |
| 21:55:42 | EXetoC | but who knows when |
| 21:56:06 | ldlework | dom96: are you suggesting just do "type Point = ref object ..." |
| 21:56:15 | ldlework | vs "type Point = ref PointObj" |
| 21:56:27 | EXetoC | so that you'll maybe just need the T proc then, but we'll see about that |
| 21:56:40 | dom96 | ldlework: I'm wondering why you need such control over whether your value is on the heap or not. |
| 21:56:55 | dom96 | Why not put all your points on the stack? |
| 21:57:26 | EXetoC | ldlework: the primary type is supposed to have just the type name, and if 'ref object' is the primary type then yes |
| 21:57:35 | Mat4 | the stack is of limited size? |
| 21:57:51 | flaviu | Mat4: That shouldn't be a problem for Points |
| 21:57:58 | EXetoC | and then you'd have PointObj for example, assuming that it's needed |
| 21:58:02 | ldlework | dom96: because once I need a reference to a point for whatever reason, now I'm hating myself because now I have no methods on the ref type |
| 21:58:09 | ldlework | where as |
| 21:58:19 | EXetoC | and then PointRef and PointPtr depending on which type is the primary one |
| 21:58:21 | ldlework | if my type is always a reference, my methods just magically work on the underlying value |
| 21:58:48 | ldlework | EXetoC: yeah I just don't like this convention |
| 21:59:03 | ldlework | looking at the type Point, you have no idea if it is a ref or a value |
| 21:59:17 | ldlework | this is bad, and I really hope the culture doesn't resolve with this convention in hand |
| 21:59:23 | EXetoC | ldlework: we did discuss earlier about syntactic sugar that would make procs taking plain objects the path of least resistance |
| 21:59:39 | dom96 | It used to be perfectly clear whether it's on the stack or on the heap (TFoo vs. PFoo) |
| 21:59:56 | ldlework | dom96: that's not needed if you just utilize the ref keyword |
| 21:59:57 | dom96 | ldlework: So you're putting it on the heap everywhere anyway? |
| 22:00:21 | ldlework | dom96: unless I specifically need it on the stack, in which case I can do so, and all my methods still work |
| 22:00:28 | ldlework | because I don't do Point = ref object |
| 22:00:31 | ldlework | I do Point = object |
| 22:00:34 | ldlework | and use ref Point everywhere |
| 22:00:43 | EXetoC | dom96: that seems best for now, because we don't have all this syntactic sugar yet |
| 22:01:29 | EXetoC | perhaps it'll be too slow, in rare cases |
| 22:03:10 | dom96 | ldlework: The idiomatic way of doing things in Nim is to either put it all on a stack or the heap. |
| 22:03:22 | dom96 | I haven't ran into a situation where I need such fine grained control. |
| 22:03:36 | ldlework | that sounds absurd |
| 22:04:03 | ldlework | Its not like I'm making any extra work for my self |
| 22:04:35 | ldlework | just being explicit |
| 22:05:00 | dom96 | I'm simply curious why you need such fine grained control over whether your data is on the stack or the heap. |
| 22:07:25 | repax | Modifying `results` guarantees return value optimisation, right? |
| 22:07:51 | * | brson joined #nim |
| 22:08:30 | EXetoC | repax: you are writing to the return address, yes |
| 22:09:03 | EXetoC | so, no C compiler optimization needed for that IIRC |
| 22:09:05 | repax | Then just alloc wherever you want first and then init the value with such a proc |
| 22:09:44 | repax | This language is wonderful |
| 22:09:44 | EXetoC | path of least resistance and all that |
| 22:10:00 | repax | I'm a least-resistance kind of guy |
| 22:11:20 | dts|pokeball | wheres the faq arag? |
| 22:11:48 | EXetoC | click the, uh, FAQ link :p |
| 22:12:06 | dts|pokeball | oh |
| 22:12:09 | dts|pokeball | i was on the wrong page |
| 22:12:44 | * | mbenadda joined #nim |
| 22:13:31 | * | willwillson joined #nim |
| 22:14:32 | EXetoC | gotta fight the modern ADD-inducing culture :p |
| 22:16:53 | dts|pokeball | the nim configuration files support env variables i presume? |
| 22:16:57 | * | mbenadda quit (Ping timeout: 240 seconds) |
| 22:21:55 | * | dain_ joined #nim |
| 22:26:58 | * | yglukhov_ quit (Quit: Be back later ...) |
| 22:33:40 | * | Nimbus joined #nim |
| 22:37:57 | * | Nimbus quit (Remote host closed the connection) |
| 22:46:19 | * | Nimbus joined #nim |
| 22:46:25 | * | yglukhov_ joined #nim |
| 22:49:05 | * | kniteli quit (Quit: Leaving) |
| 22:49:26 | * | kniteli joined #nim |
| 22:59:20 | * | Nimbus quit (Read error: Connection reset by peer) |
| 22:59:43 | * | Nimbus joined #nim |
| 23:04:16 | * | boydgreenfield joined #nim |
| 23:05:46 | * | nimnoob joined #nim |
| 23:11:18 | * | Nimbus quit (Remote host closed the connection) |
| 23:12:33 | dom96 | Update your git people https://github.com/blog/1938-git-client-vulnerability-announced |
| 23:13:50 | dts|pokeball | hey dom96 can you help me with something real quick? |
| 23:13:51 | dts|pokeball | https://github.com/DTSCode/Nimbus |
| 23:13:54 | EXetoC | don't use windows |
| 23:14:01 | EXetoC | jk |
| 23:14:12 | dts|pokeball | nim cant properly compile anymore because of the eval.nim.cfg file |
| 23:14:41 | dts|pokeball | but i followed this page http://nim-lang.org/niminst.html and looked at the devel cfg file and cant figure out whats wrong |
| 23:15:00 | ldlework | OSX uses a case insensitive filesystem? |
| 23:15:26 | dom96 | dts|pokeball: Have you tried tracert? :P |
| 23:15:59 | dts|pokeball | no |
| 23:19:56 | * | nimnoob quit (Remote host closed the connection) |
| 23:20:41 | * | Nimbus joined #nim |
| 23:21:32 | * | brson quit (Ping timeout: 256 seconds) |
| 23:22:10 | * | Nimbus quit (Remote host closed the connection) |
| 23:22:29 | * | Nimbus joined #nim |
| 23:23:58 | dom96 | dts|pokeball: what are you trying to do? |
| 23:24:05 | dom96 | I think it should be --cc |
| 23:24:19 | dom96 | also the name should match your main file. |
| 23:24:28 | * | brson joined #nim |
| 23:24:29 | EXetoC | it's not needed for other options |
| 23:24:54 | EXetoC | are there any exceptions? it seems possible to omit -- in general |
| 23:24:59 | ldlework | dom96: You say it is 'so fine grained', but really, I'm not doing anything in particular. I'm simply not defining a ref type. |
| 23:25:28 | ldlework | I use references everywhere, except when I need something on the stack. I define all my methods on the value type. It works out fine. |
| 23:25:50 | dts|pokeball | dom96, its for the eval bot. it writes the code to a file called eval.nim |
| 23:25:53 | dts|pokeball | and ok. ty |
| 23:26:13 | dts|pokeball | also, what im trying to do is to get it to use a compiler other than the system compiler |
| 23:26:40 | dom96 | I see. |
| 23:26:56 | dom96 | Then yeah. Use --cc:ucc or cc = ucc |
| 23:27:07 | dts|pokeball | but then how do i tell it what ucc is? |
| 23:27:30 | dts|pokeball | because the compiler wont be on the path. it will be local in Nimbus' directory |
| 23:27:31 | dom96 | in your nim compiler config file I guess. |
| 23:27:55 | dts|pokeball | path = "the/path/to/pcc"? |
| 23:28:53 | dom96 | no |
| 23:29:07 | EXetoC | that's for module paths |
| 23:29:20 | dom96 | Look at your $nimDir/config/nim.cfg |
| 23:29:25 | dts|pokeball | ok |
| 23:29:38 | * | Nimbus quit (Remote host closed the connection) |
| 23:30:07 | * | Nimbus joined #nim |
| 23:30:51 | * | Nimbus quit (Remote host closed the connection) |
| 23:31:12 | * | Nimbus joined #nim |
| 23:34:45 | dts|pokeball | oh i get it. amd64.linux.ucc.exe = "/path/to/pcc" |
| 23:35:31 | * | Nimbus quit (Remote host closed the connection) |
| 23:35:53 | * | Nimbus joined #nim |
| 23:35:54 | * | Nimbus quit (Remote host closed the connection) |
| 23:36:12 | reactormonk | dom96, ah, thanks. |
| 23:37:10 | * | Nimbus joined #nim |
| 23:37:46 | * | Nimbus quit (Remote host closed the connection) |
| 23:38:36 | * | j3rky joined #nim |
| 23:44:26 | dts|pokeball | do the errors in #nim-offtopic mean that nim is passing invalid linking parameters to pcc? |
| 23:45:37 | Mat4 | ciao |
| 23:45:41 | * | Mat4 left #nim (#nim) |
| 23:49:04 | EXetoC | you need to link against libdl |
| 23:49:14 | EXetoC | look for -ldl in the config |
| 23:49:25 | dts|pokeball | hmmm |
| 23:50:02 | EXetoC | I think it'll work if you do the same for ucc, unless the flags are different |
| 23:50:02 | dts|pokeball | ty |
| 23:50:42 | reactormonk | boydgreenfield, fancy styling btw. |
| 23:51:07 | ldlework | fancy styling? |
| 23:51:14 | dts|pokeball | much thanks EXetoC and dom96!!! |
| 23:52:13 | reactormonk | ldlework, see github issue |
| 23:53:05 | * | nimnoob joined #nim |
| 23:57:52 | EXetoC | I wonder if this cparser library works |