| 00:32:41 | * | XAMPP joined #nimrod |
| 00:32:41 | * | XAMPP quit (Changing host) |
| 00:32:41 | * | XAMPP joined #nimrod |
| 00:56:10 | * | XAMPP_ joined #nimrod |
| 00:56:30 | * | XAMPP_ quit (Read error: Connection reset by peer) |
| 00:59:24 | * | XAMPP quit (Ping timeout: 260 seconds) |
| 01:52:21 | * | XAMPP joined #nimrod |
| 01:52:22 | * | XAMPP quit (Changing host) |
| 01:52:22 | * | XAMPP joined #nimrod |
| 03:20:12 | * | FreeArtMan quit (Ping timeout: 252 seconds) |
| 07:11:09 | * | gour joined #nimrod |
| 08:07:31 | gour | morning |
| 08:23:30 | * | gour is reading backlogs discovering interesting things :-) |
| 08:38:57 | * | gour quit (Disconnected by services) |
| 08:39:00 | * | gour_ joined #nimrod |
| 09:32:33 | * | gour_ is building from the trunk in order to try aporia |
| 09:34:03 | gour_ | but build instructions are not correct...iow. s|cd Nimrod|cd Nimrod/build| |
| 09:34:18 | * | gour_ is now known as gour |
| 09:41:25 | gour | cool...we have aporia running on our box :-) |
| 09:46:26 | * | gour quit (Disconnected by services) |
| 09:46:28 | * | gour_ joined #nimrod |
| 09:48:41 | * | gour_ is now known as gour |
| 09:48:56 | gour | how is autosuggest feature in aporia activated? |
| 09:51:37 | fowl | gour: edit -> preferences |
| 09:51:44 | fowl | gour: i dont recommend it though |
| 09:52:32 | gour | fowl: that i did, but how it works in the pane? tab does not activate it? |
| 09:53:52 | fowl | it comes up as you type |
| 09:55:00 | gour | hmm |
| 09:59:35 | gour | i just wonder why i fiddle with a language having 200 / 10 users and not just focusing on broadly-supported ada :-} |
| 10:05:03 | fowl | i like it because i can work really quickly |
| 10:06:45 | gour | fowl: what langs you were using before nimrod? |
| 10:15:20 | fowl | gour: ruby |
| 10:19:22 | * | Araq_ joined #nimrod |
| 10:22:04 | gour | however, i must say that, despite of having dozen users only, i appreciate many things in nimrod's ecoystem |
| 10:23:33 | gour | zahary is probably vim user, but wonder about other core dev(s) |
| 10:25:13 | gour | fowl: i was interested in ruby long ago and remembering talk about ruby2 which is not manifested yet |
| 10:34:13 | Araq_ | gour: we use aporia |
| 10:34:17 | Araq_ | have to go, see you later |
| 10:34:22 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0/20121119183901]) |
| 11:14:48 | * | _ponce quit (Remote host closed the connection) |
| 11:15:05 | * | _ponce joined #nimrod |
| 12:15:48 | * | XAMPP quit (Read error: Connection reset by peer) |
| 13:09:10 | * | q66 joined #nimrod |
| 13:18:09 | * | FreeArtMan joined #nimrod |
| 13:23:58 | gour | nimrod was mentioned recently (~1hr ago) in#ada in not so bright context...check #ada log if it does exist |
| 14:55:32 | * | FreeArtMan quit (Ping timeout: 265 seconds) |
| 14:57:55 | * | gradha joined #nimrod |
| 15:00:12 | gradha | Last night, before falling asleep, I had a dream |
| 15:00:28 | gradha | a dream with a grand vision for nimrod |
| 15:00:49 | gradha | let me tell you of this dream |
| 15:01:05 | gradha | coders, all genders and ages would stumble on nimrod or be told about it |
| 15:01:20 | gradha | they would read a few of its characteristics and become interested in the language |
| 15:01:32 | * | q66 quit (Quit: Quit) |
| 15:01:34 | gradha | they would take a look at the documentation online, and browse through the help |
| 15:01:54 | gradha | fascinated with what they saw, they would continue reading, through lush interesting examples |
| 15:02:10 | gradha | clicking here, there, simply by curiosity they would learn the language, and it would be fun |
| 15:02:21 | gradha | so much fan that they would fall in love with the language and start using it |
| 15:02:35 | gradha | that day, is not far away, it is my dream, and now it is your dream too |
| 15:02:53 | gradha | it is in my hands to make this dream come true, and so will I work for this goal |
| 15:03:09 | gradha | because such dreams can't be let to rot in one single mind |
| 15:03:22 | gradha | ahem |
| 15:03:39 | gradha | and now I will translate |
| 15:03:58 | gour | gradha: one user spoke badly about new langs with bells & whistles (like nimrod & rust) and not caring for correctness |
| 15:04:00 | gradha | I can imagine performing several steps in order to improve the documentation of nimrod |
| 15:04:32 | gradha | 1) incorporate examples directly into the documentation |
| 15:05:03 | gradha | it would be possible to create a simple "examples.html" index file, generated from the filenames of the examples folder |
| 15:05:30 | gradha | the files would be exported to HTML in codeblocks with syntax highlighting, so now they can be browsed online and referenced from other parts of the documentation as well |
| 15:05:48 | gradha | 2) through exposure of the examples, we would see, as Araq said, they are mostly small test cases |
| 15:06:19 | gradha | this would prompt us to improve and document them properly. For instance, start each one with a single short sentence, then a longer paragraphs description of what it is trying to teach the reader |
| 15:06:50 | gradha | thus, the generated index could extract this information and it would be a little bit more than an html-ified listing of examples, as each would have a description of what it does |
| 15:07:22 | gradha | 3) improve nimdoc to generate meaningful table of contents which can be predicted |
| 15:07:44 | gradha | this would ease hyperlinking, and documentation linkage would be less painful |
| 15:07:47 | gour | gradha: which editor you use? |
| 15:07:54 | gradha | gour: vim |
| 15:08:22 | gradha | 4) having proper html linkage, the compiler idetools would be improved to parse the examples and generate html links to all procs |
| 15:08:49 | gradha | this would improve the html examples in that anybody could merely click a library proc, and directly go to where it is documented |
| 15:09:21 | gradha | since this would be provided by the compiler, it would easily distinguish between procs named the same in different modules, which tends to be the biggest obstacle for documentation generation without compiler support |
| 15:09:47 | gradha | 5) now that examples link to library documentation, a simple sqlite database can be used, saying which example uses which library procs |
| 15:10:10 | gradha | through a second pass documentation generation, now library documentation procs can be extended to include a note on "where is this proc being used" |
| 15:10:33 | gradha | with this, somebody browsing the proc "strutils.split", can immediately jump to a real example using it |
| 15:11:37 | gradha | 6) just like idetools allows an editor to jump to a proc, it could be made to also provide documentation for that proc, so editors can display tooltips about the proc just by hovering the mouse on a keyword, or keyboard shortuc |
| 15:12:03 | gradha | this would bring aporia (et al) to be on the same level playing field as big names in the industry, like visual studio or eclipse |
| 15:12:26 | gradha | ok, I think that's all I remember from yesterday nights |
| 15:12:54 | * | gour will reflect on it later (in the evening) |
| 15:13:05 | gradha | at some unknown point in the future will start with 1), then see how it goes |
| 15:15:04 | gradha | gour: with regards to users/channels/people speaking bad about languages, that's the norm, so I wouldn't worry |
| 15:15:22 | gradha | it's easier to have two coders agree on a language they hate than a language they like |
| 15:15:36 | gradha | after all, it's all just a disguised religion |
| 15:16:54 | gour | :-) |
| 15:19:18 | * | gour consider that step 0) in the above plan should be: 0) bring nimrod to, at least, debian & ubuntu |
| 15:20:37 | gradha | I'm not a linux user, but is that a problem now? at least until 1.0 you would be using the git version anyway |
| 15:22:21 | gour | people using debian & git who are not full-fledged devs, prefer to use package manager |
| 15:22:51 | gour | and those two are big distros...how to find nimrod at first place? |
| 15:23:07 | gour | see about go/D/rust etc. |
| 15:24:22 | gour | waiting for 1.0 means new programmers might pick another lang |
| 15:25:35 | gradha | packaging for distros tends to be a political problem, you need somebody with a thick skin who talks well |
| 15:25:36 | gour | nimros is probably more stable than D2, but it's not in official repos |
| 15:25:56 | gradha | wait, D2 is not stable YET? |
| 15:26:03 | gradha | oh man, what are they waiting for? |
| 15:26:29 | gradha | they are going to go the way of the HURD |
| 15:26:41 | gour | just read the other day how 2.0.59 --> 2.0.60 breaks people's code |
| 15:26:59 | * | q66 joined #nimrod |
| 15:27:07 | gour | they're probably not clear |
| 15:27:36 | gradha | well, you heard Araq the other day, it's planned to have a little breackage before 1.0 |
| 15:27:52 | gradha | if you have a package for a language now, that gives the scent of being "stable" |
| 15:28:11 | gradha | could make the early adopters hate the language for breaking their programs |
| 15:28:33 | gour | well, it's 0.9.x...many things in distros are < 1.0 |
| 16:07:02 | gour | being early adopter means one is aware that code can break, especially if it's announced/anticipated unlike in D2 |
| 16:07:46 | gour | but, the point is to expose language to early adopters...how can one stumble on it today? |
| 16:07:56 | gradha | luck |
| 16:08:07 | gour | that's not enough for wider adoption |
| 16:08:15 | gradha | write blog posts about how awesome it is |
| 16:08:32 | gradha | rewrite something useful in nimrod, prove it is better than original language |
| 16:08:54 | gour | i'll when/if manage to do something with it...attempt to do c2nim on my header file failed |
| 16:09:26 | gour | i'm more for writing new than rewriting |
| 16:09:42 | gradha | then you could write a blog post about how c2nim is horrible, bad talking brings in more people to bitch in |
| 16:09:58 | gour | nah..it's too early :-) |
| 16:10:29 | gour | otoh, it's not so horrible - just tmp/swe/swephexp.h(470, 37) Error: ';' expected |
| 16:11:04 | gradha | ah, unexpected guests, the spice of life |
| 16:11:13 | gour | expecting guests to arrive soon and going afk..bbl |
| 16:11:24 | gour | mine are expected :-) |
| 16:11:46 | gour | in the evening i've some questions for our designer if he shows up |
| 16:12:09 | gradha | you can always ask any time, they tend to read irc logs |
| 16:12:30 | gradha | or post in the forums |
| 16:12:55 | gour | yeah, i read yesterday's backlog as well...not 200 nimrod users, but reduced by factor of 10 :-) |
| 16:13:18 | gradha | who knows, it's a joke around here that nobody uses nimrod |
| 16:13:33 | gour | it does not matter to me...i'm accustomed to not be in majority for important things |
| 16:13:40 | gour | (in my life) |
| 16:13:49 | * | gour --> afk |
| 16:42:56 | dom96 | Nice to hear that gradha is dreaming about Nimrod now heh |
| 16:43:23 | gradha | I never remember dreams, this was before falling asleep |
| 16:43:23 | dom96 | I like your ideas. Especially that idea with examples: being able to find an example which uses a specific proc; brilliant. |
| 16:44:15 | dom96 | But yeah, if only I had more time, we would have some of these features now. |
| 16:44:25 | dom96 | I definitely want to get on par with Visual Studio |
| 16:44:46 | dom96 | Might be too ambitious a goal though heh |
| 16:45:28 | gradha | the long term benefit of interlinked documentation is that you stop creating silly oneliner examples in the documentation for procs, since they hyperlink the true stuff |
| 16:45:43 | gradha | you can concentrate on documenting the proc, and also concentrate on explaining or teaching how to use it |
| 16:46:13 | dom96 | yeah, although implementation wise, it could be quite a bit of work |
| 16:46:39 | gradha | given enough time and motivation I can do wonders |
| 16:46:55 | gradha | so if you keep youtube away from me and wait, something good might happen |
| 16:47:17 | dom96 | great :D |
| 16:49:52 | gradha | what would be the equivalent of strutils.align, but pad a string with zeroes? |
| 16:52:13 | dom96 | repeatChar(5, '0') & str |
| 16:53:11 | gradha | Hmm, I can certainly append the string to the maximum filler and cut it off |
| 17:07:18 | gradha | what's the quick way to transform an iterator into a sequence without writing your own loop? |
| 17:10:28 | dom96 | change the iterator into a proc and make it return a seq? :P |
| 17:21:28 | * | FreeArtMan joined #nimrod |
| 17:36:29 | Araq | gradha: there is a 'toSeq' somewhere hidden in sequtils or in the tests/ |
| 17:36:48 | Araq | document it, test it, add it to ... I dunno |
| 17:37:10 | gradha | sequtils? |
| 17:38:48 | dom96 | http://build.nimrod-code.org/docs/sequtils.html |
| 17:40:46 | Araq | wow somebody updates sequtils to use closures :-) |
| 17:40:49 | Araq | *updated |
| 17:43:22 | gradha | I've just written a nimrod program which proves nobody uses my objc programs |
| 17:43:38 | gradha | maybe today is irony day |
| 17:48:36 | Araq | ugh what's the name of that crappy linux terminal program to control audio? |
| 17:48:47 | gradha | aumix? |
| 17:48:55 | Araq | nope |
| 17:48:57 | dom96 | alsamixer? |
| 17:49:04 | Araq | yep |
| 17:49:33 | Araq | how come it can't keep its settings? |
| 17:49:55 | gradha | you need to add some "alsamixer -loadprevioussavedparameters" to your init.rc or something |
| 17:50:01 | gradha | happens with aumix too |
| 17:51:03 | gradha | I believe the problem is the kernel module for audio starts with volume zero as default initialization value, so you need to set it at some point to a sane value |
| 17:51:24 | dom96 | Doesn't pulseaudio handle it though? |
| 17:51:27 | dom96 | Or are you not using it? |
| 17:52:30 | dom96 | This could be happening perhaps: https://wiki.archlinux.org/index.php/PulseAudio#Pulse_overwrites_ALSA_settings |
| 17:54:27 | Araq | I've long stopped fixing linux related stuff |
| 17:55:48 | gradha | you should get a mac, at least there you can't fix it even if you want it |
| 18:00:20 | Araq | yeah instead I can convince myself it's a feature for my own good |
| 18:00:42 | Araq | and that's a stupid idea to use a computer for work to begin with |
| 18:01:28 | gradha | yeah, workstations are were work is supposed to stop |
| 18:01:44 | Araq | after all, it was more expensive than an ordinary PC so it must be superior ... |
| 18:27:13 | gradha | does nimrod optimize away an if branch if you pass a constant? |
| 18:28:49 | Araq | no, GCC does |
| 18:29:01 | Araq | nimrod should though |
| 18:29:08 | * | Araq adds it to his todo |
| 18:29:34 | Araq | you can use 'when' though |
| 18:30:19 | gradha | so I added toSeq(iter) to sequtils |
| 18:30:32 | gradha | but I can't add a specialized toSeq(iter: expr; seqSize: int) |
| 18:30:42 | gradha | I get "tests/run/ttoseq.nim(7, 15) Error: wrong number of arguments" |
| 18:30:49 | gradha | when calling the first version |
| 18:30:58 | Araq | that's strange |
| 18:32:34 | gradha | hmmm... it works if I duplicate it straight in the ttoseq.nim file |
| 18:34:22 | Araq | I bet you put the definition after the usage then |
| 18:34:35 | gradha | yes, it fails only when the template is in the sequtils module |
| 18:34:49 | gradha | steps: go to tests/run/ttoseq.nim and duplicate toSeq adding a parameter |
| 18:34:56 | gradha | ttoseq compiles and runs fine |
| 18:35:13 | gradha | move both templates to sequtils, import that in ttoseq, now it doesn't compile |
| 18:37:17 | Araq | gist? |
| 18:37:48 | gradha | as in the contents of sequtils? |
| 18:38:13 | Araq | yeah |
| 18:39:02 | gradha | https://gist.github.com/4278581 |
| 18:39:16 | gradha | haven't actually implemented it, just duplicated the proc and added the param |
| 18:40:27 | Araq | that's not a bug |
| 18:40:36 | Araq | immediate templates can't be overloaded |
| 18:40:49 | Araq | ok the error message could be better |
| 18:41:03 | gradha | but why does it seem to work if I don't move the templates to the module? |
| 18:41:12 | gradha | or at least the compiler doesn't complain then |
| 18:41:32 | Araq | ok ok, it is a bug that the compiler doesn't moan |
| 18:41:52 | gradha | ah, it does when I try to *use* the other template |
| 18:42:04 | Araq | it looks up some of the two at random yes |
| 18:42:05 | gradha | so maybe being inside a module changes their order |
| 18:42:27 | Araq | it's a hash table lookup |
| 18:42:41 | Araq | so whatever happens to be first there gets picked |
| 18:42:42 | * | fowl quit (Ping timeout: 264 seconds) |
| 18:42:52 | Araq | and it's a known bug :P |
| 18:42:54 | Zor | Araq: you compile to C, right? |
| 18:43:17 | Araq | Zor: yes |
| 18:43:27 | Zor | how do you deal with utf-8 string literals? |
| 18:44:25 | Araq | what about them? |
| 18:44:55 | Zor | well, C doesn't support them until C11 |
| 18:45:03 | Zor | (and even then it seems most compilers don't support them) |
| 18:45:15 | Araq | but it supports \xFA\x0F |
| 18:46:02 | Zor | so do you just encode all utf-8 strings like that? |
| 18:46:58 | Araq | I encode the bytes >= 128 like that |
| 19:11:18 | * | fowl joined #nimrod |
| 19:28:27 | * | XAMPP joined #nimrod |
| 20:00:22 | Araq | so gradha, lets talk about how to generate a stable ID for the documentation generator |
| 20:00:40 | Araq | because that's what hinders cross linking |
| 20:00:51 | gradha | procname+paratypes? |
| 20:01:21 | Araq | but that's too long |
| 20:01:39 | Araq | and it should be modulename+procname+parameters |
| 20:01:58 | Araq | but wait, you don't like unique module names either |
| 20:01:58 | gradha | isn't modulename implicit by the html file? |
| 20:02:12 | Araq | hrm ok |
| 20:02:20 | gradha | don't I like them? |
| 20:02:56 | gradha | you know, in html you can use several <a> markers for the same point |
| 20:03:04 | gradha | you can leave the numeric ones, and add a few more |
| 20:03:10 | gradha | it should still work |
| 20:03:33 | gradha | linking something unambiguos allows using the short version, if there are problems, use the longer version |
| 20:03:39 | gradha | at lest that's for manually written links |
| 20:03:44 | Araq | that's too complex |
| 20:03:47 | gradha | for automatic links you don't care, since they are automatic |
| 20:04:05 | Araq | and we need that mapping for more stable C output too |
| 20:04:32 | gradha | what's the complex part? |
| 20:04:37 | Araq | so it needs to be package_module_procname_encodedParams |
| 20:04:54 | Araq | but that's too verbose |
| 20:05:12 | gradha | aren't you mixing html toc ids with C export pragma? |
| 20:05:20 | gradha | I thought they were separate |
| 20:09:02 | Araq | they are separate |
| 20:09:32 | Araq | however it's you who wanted more stable C identifiers to be generated without 'exportc' |
| 20:10:22 | gradha | not really wanted, as in I reported a clash, from a specially prepared example to fail |
| 20:10:58 | Araq | well you wanted the type name to be stable for header generation |
| 20:11:14 | Araq | the sqlite handle was it I think |
| 20:12:09 | gradha | ah, but that's not about procs or params, its about types really |
| 20:12:55 | gradha | the issue there is that as a nimrod programmer you don't have to explicitly exportc types |
| 20:13:06 | gradha | after all, maybe you think type X won't be useful for anybody |
| 20:13:17 | gradha | until that somebody comes and cries you a river about the weird C exported name |
| 20:13:47 | gradha | you could solve that issue inelegantly by allowing the user to tell the compiler "whenever you find X, use name Y" |
| 20:14:26 | gradha | but automatic naming rules would be good anyway |
| 20:14:35 | Araq | I think we should do: name_hash where hash is computed from the module, package and signature |
| 20:14:36 | gradha | so package_module_type for sqlite |
| 20:15:00 | gradha | BTW, what are packages |
| 20:15:02 | gradha | ? |
| 20:16:05 | gradha | name_hash seems fair to me, other than possibly having two similar hashes break generation |
| 20:16:42 | gradha | at least then you can use #define or typedef to make it more user friendly |
| 20:18:33 | Araq | well people like their module names to be 'common', 'utils' and 'types' and currently the module's name must be unique per project |
| 20:18:55 | Araq | so that will clash very soon and we need some notion of a package |
| 20:19:43 | gradha | if you include the full import path in the hash, that allows people to have the dreaded A.B.C.D you love |
| 20:20:33 | gradha | unless by package you mean something else at language level |
| 20:20:52 | Araq | but that's wrong too: /home/araq/moduleA will become /home/gradha/moduleA on your machine |
| 20:21:01 | Araq | so we can't just use the full path |
| 20:21:15 | gradha | no, I meant the relative path from the base import |
| 20:21:16 | Araq | and it's not specified which part of the path is in fact the package name |
| 20:21:29 | Araq | relative path looks fragile too |
| 20:21:32 | gradha | so if you have moduleA with proc X, and moduleB with proc X, they become moduleA.X and moduleB.X |
| 20:21:51 | gradha | then, if you put that inside moduleC you get moduleC.moduleB.X |
| 20:22:21 | gradha | which will become a problem for partial compilation |
| 20:22:37 | gradha | hmm... I guess there is no concept yet of nimrod binary libraries |
| 20:24:21 | gradha | btw, even in the sqlite type exportc I got easily around creating a new nimrod structure and interfacing to it from my nimrod interface code |
| 20:24:30 | gradha | so I avoid any naming issues at all |
| 20:25:52 | * | XAMPP_ joined #nimrod |
| 20:27:33 | Araq | that's good ;-) |
| 20:34:43 | * | XAMPP quit (*.net *.split) |
| 20:34:43 | * | FreeArtMan quit (*.net *.split) |
| 20:34:43 | * | reactormonk quit (*.net *.split) |
| 20:38:47 | gour | evening Araq |
| 20:40:37 | * | FreeArtMan joined #nimrod |
| 20:40:55 | Araq | hi gour |
| 20:41:26 | gour | didn't have much time for nimrod today, but built it from the trunk as well as aporia and c2nim which i tested with my 3rd party C lib's header - it fails with 'tmp/swe/swephexp.h(470, 37) Error: ';' expected' and the header is here: http://pastebin.com/KG7nyfLf |
| 20:41:34 | gour | any idea what confuses it? |
| 20:42:41 | * | reactormonk joined #nimrod |
| 20:44:01 | Araq | replace #define by #def |
| 20:44:56 | gour | on that line or globally? |
| 20:45:16 | Araq | on that line |
| 20:45:21 | gour | ok. let me try |
| 20:45:26 | Araq | read c2nim's docs ;-) |
| 20:47:41 | * | NimBot_ quit (*.net *.split) |
| 20:47:56 | gour | tmp/swe/swephexp.h(473, 30) Error: ';' expected |
| 20:49:11 | gour | ah, now i've arrtived at #def directive |
| 20:49:31 | Araq | oh yeah the couple of #define's need to become #def too |
| 20:49:36 | Araq | like #define EXP16 |
| 20:50:11 | gour | ok, will tackle that tomorrow |
| 20:50:51 | gour | let me check yesterday's log before asking something... |
| 20:57:22 | gour | when asked about type-safety in the context of "For better interfacing to other programming languages, the symbols of enum types can be assigned an explicit ordinal value.", you did answer with: "the compiler disallows array[enumWithHoles, T], so no it's not". i'm not sure whether it is 1005 clear to me, so let's ask this way: having TDirection as in enumeration example, and var x = south, i wonder does |
| 20:57:32 | gour | compiler allows something as var y = x +1 ? |
| 21:00:37 | gradha | the compiler disallows that |
| 21:01:22 | gour | so, one can define specialized arithmetic for one's own types? |
| 21:01:42 | gradha | yes |
| 21:01:52 | gradha | the error would be https://gist.github.com/4279833 |
| 21:02:12 | gradha | there, x is a TMonth enum from the times module |
| 21:02:17 | gour | that's cool and as it is in haskell...very nice |
| 21:03:12 | gour | ada can do it as well, right? (or we'll forget about it immed.) |
| 21:03:52 | gour | such strictness of type-engine is what we're looking for without the need to grok monads :-) |
| 21:05:12 | Araq | Ada does the same, yes |
| 21:05:22 | gour | what is the meaning of "For better interfacing to other programming languages, the symbols of enum types can be assigned an explicit ordinal value." then? only initializaion or what is allowed? it confuses me a bit |
| 21:06:12 | Araq | you can do: ord(myEnum) to get the underlying number |
| 21:06:32 | Araq | so that's what the "explicit ordinal value" refers to |
| 21:06:37 | gour | that's tolerable :-) |
| 21:07:32 | gour | when it says "can be assigned", does it mean it is also possible to prevent it? |
| 21:08:32 | Araq | it means the compiler assigns a value for you otherwise |
| 21:09:02 | Araq | you can't prevent it as you need to assign some bit pattern to it because that's how computers work |
| 21:09:37 | gour | i'm thinking about ADT or sealed box which allows changing values of certain type only via specific interface functions |
| 21:11:52 | gour | Araq: you told me yesterday that nimrod is lacking a bit with OOP/FP features, i'm more interested for FP, like pattern matching, higher-order-functions as well as currying or partial applications...is anything from that in stock for 1.0? |
| 21:12:17 | Araq | we have higher order functions and first class functions |
| 21:12:42 | gour | uhh...have to do some reading then |
| 21:13:02 | Araq | we have some simple form of pattern matching with 'case' statements |
| 21:13:22 | Araq | and you can build more elaborative pattern matching with a macro |
| 21:13:32 | gour | D is lacking those as well and we liked it in haskell |
| 21:13:52 | Araq | you can implement currying via a macro |
| 21:14:02 | gour | ok |
| 21:14:17 | gour | what are some important things planned for 1.0? |
| 21:14:32 | gour | (still not finished) |
| 21:15:17 | Araq | we need better support for non-nullable types |
| 21:15:37 | Araq | and some better form of construction for 'case' objects |
| 21:16:02 | Araq | overloading of the assignment operator |
| 21:16:12 | Araq | and better support for destructors |
| 21:16:32 | Araq | and a shared GC'ed memory heap |
| 21:19:18 | gour | in D i was planning to use subset of the language called 'safe D'...it looks nimrod is ready for it |
| 21:19:53 | Araq | there is no such thing as a "safe D" |
| 21:20:18 | Araq | the memory safety of D is so full of holes that it's all wishful thinking and marketing |
| 21:20:33 | gour | indeed |
| 21:21:03 | gour | what is your stanza on purity? D is trying to mimic some FP stuff... |
| 21:22:18 | gour | of course, purity in FP sernse, not nimrod's library-sense |
| 21:23:13 | Araq | we have 'noSideEffect' and an effects system in place that accomplishes similar things |
| 21:23:18 | Araq | as FP's purity |
| 21:23:58 | Araq | but: did ever occur to you that if I would want a pure FP language, I would have invented a pure FP language? |
| 21:24:13 | zahary | Araq, why do you consider D less memory safe? besides the leaks I found one memory safety related crash in the GC |
| 21:24:23 | gour | thank you for your patience giving answers which are probably obvious by careful reading... |
| 21:24:53 | Araq | oh hi zahary :-) |
| 21:24:58 | gour | Araq: well, i believe haskell does not need much competition as pure FP language |
| 21:25:03 | zahary | if it's because of internal pointers, we have those too |
| 21:25:18 | Araq | we don't have those |
| 21:25:33 | Araq | the type system has a hole, yeah |
| 21:25:53 | Araq | because you pushed for 'var T' as a return type |
| 21:26:03 | Araq | but that's about it |
| 21:26:13 | gour | Araq: but having some sort of referential integrity for certain set of functions/prcoedures is not bad idea, imho |
| 21:26:33 | Araq | unless you found a new one :D |
| 21:26:58 | zahary | sure we do: |
| 21:27:03 | zahary | var globalSeq: seq[TSomeObject] |
| 21:27:08 | zahary | proc foo(x: var TSomeObject) = |
| 21:27:13 | zahary | globalSeq.setLen(0) |
| 21:27:18 | zahary | foo(globalSeq[3]) |
| 21:27:53 | zahary | var is not really needed, but it illustrates what I mean. interior pointers are easily created |
| 21:28:13 | Araq | but they are all on the stack |
| 21:28:33 | zahary | not here - I made interior pointer into the globalSeq memory that is going to be deallocated in the setLen call |
| 21:29:53 | * | zahary quit (Read error: No route to host) |
| 21:32:03 | Araq | hu? that's just aliasing ... :P |
| 21:32:58 | gour | Araq: what do you think about providing debian/ubuntu pacakges and/or pushing nimrod in the distro? |
| 21:37:19 | Araq | these things are likely to cost quite some time |
| 21:37:34 | Araq | so if you want to do that, feel free |
| 21:37:44 | Araq | but I don't really care about it |
| 21:39:14 | gour | ok |
| 21:39:34 | gour | you copy haskell's "no success at any cost"? |
| 21:40:04 | Araq | certainly not ;-) |
| 21:40:54 | gour | without exposure of language to the users - and debian and ubuntu have lot of them - how will new/okd programmers start using nimrod? |
| 21:42:19 | Araq | you mean programmers can't download stuff from github these days? |
| 21:42:24 | dom96 | gour: Why don't you add it to the debian/ubuntu repos then? |
| 21:43:04 | dom96 | Nimrod is already in the AUR because it's easily done. But complying with all those debian/ubuntu standards is a lot more work. |
| 21:43:34 | dom96 | A .deb file can already be easily created though. |
| 21:43:44 | gradha | you could argue: once a package is in a distro, how do you make people know it exists with zillions of packages? the problem is marketing, not the packaging/distribution format |
| 21:43:54 | gour | dom96: going into debian/ubuntu requires time...i'm new debian user and not dev...sure, more work, but also much more users...so many debian-based linux distros and it has certain image as well in the eyes of devs |
| 21:44:34 | gour | gradha: see, i'm preaching to some devs (php cms) about fossil...first question is how is called the package for ubuntu |
| 21:45:04 | gour | gradha: and saying 'build from source' means many won't bother |
| 21:45:14 | gradha | well, if they are afraid from getting outside of their packages, that's sad |
| 21:45:54 | gradha | last time I used debian I had over 40 packages manually installed, just because the packagers were assholes and/or didn't include the dependencies I wanted |
| 21:45:59 | gour | called it as you like, but debian is pretty much standard dev machine |
| 21:46:24 | gradha | I guess gentoo people have it easier |
| 21:46:54 | gour | i spent >5yrs with gentoo on ~amd64...and,no more, thank you |
| 21:47:24 | fowl | its not that hard to build a .deb |
| 21:47:29 | gour | when the package is in debian it gives (some) security it won't create havoc on your machine, that's the point |
| 21:47:54 | gour | arch's AUR (i spent > 5yrs with it as well before moving to debian) is another category of trust :-) |
| 21:48:14 | gour | fowl: right, but to push it in the distro is another thing |
| 21:48:24 | gradha | people who want debian for stability use stable, they wouldn't accept your testing/untesting packages even if you pointed at them with a gun |
| 21:48:44 | gradha | so it's either debian+testing/unstable or debian+custom packages/source install |
| 21:48:54 | gour | many devs use sid |
| 21:49:34 | gour | and package, afaik, has to go through sseveral stations, it cannot enter in stable out of big blue sky |
| 21:50:04 | gour | anyway, just advising... |
| 21:50:19 | gradha | so if you packaged nimrod today, when would it reach stable? |
| 21:51:34 | dom96 | what we need is what Rust/D constantly have: tons of blog posts of random users saying "Look at these pretty features, look what I can do with them! I <3 this language." |
| 21:51:54 | gour | gradha: maybe in ~3 years |
| 21:52:24 | gour | at the moment, testing is frozen - since summer and next stable will be next year...maybe feb/mar |
| 21:52:54 | gour | then you can count ~2 years until next stable |
| 21:52:59 | dom96 | from my experience with Ubuntu, waiting this long for new software is very annoying. |
| 21:53:14 | dom96 | Which is why I use Arch Linux now. |
| 21:53:54 | gour | as i wrote, many devs use sid which has bleeding edge, i use wheezy (testing) atm and i'm happy having stable machine without the need for much tweaking |
| 21:54:19 | gour | arch's quality deteriorated significantly in last few years, imho |
| 21:54:34 | gour | after so many new users arrived |
| 21:56:54 | gour | check donwload offering for (unstable D): http://dlang.org/download.html |
| 21:58:19 | * | gour notices new 'challenges' for nimrod from SPARK lover in #ada |
| 21:59:34 | gradha | man, this GUI stuff is awesome, I clicked #ada and it logged me there! How can I read their channel log? |
| 21:59:44 | gour | Araq, "and sorry, Spark embraces imperative code just as much as Nimrod does" - I'm not sure |
| 21:59:49 | gour | what you mean by "embraces" (I'm ok with it's being imperative though). You can reason about |
| 21:59:55 | gour | imperative code in SPARK. Can you in Nimrod? Is it a future goal? |
| 22:00:05 | gour | that's latest |
| 22:03:55 | gradha | I found what broke in idetools |
| 22:04:05 | gradha | well, at least I found what is breaking it for me |
| 22:04:15 | Araq | what is it? |
| 22:04:20 | gradha | when I run the idetools command inside the nimrod source tree it works |
| 22:04:35 | gradha | when I run the idetools command in some other project outside, it fails |
| 22:04:40 | gradha | the error is "Error: arguments can only be given if the ''--run'' option is selected" |
| 22:04:55 | gradha | at least that's what the vim log reports |
| 22:05:15 | gradha | I'll try other directories now |
| 22:05:25 | gour | gradha: part of backlog if it helps - http://pastebin.com/0qGuU9du |
| 22:06:15 | gradha | crap, it works on my aporia checkout, so maybe it doesn't like my other project paths |
| 22:07:05 | gradha | oh, right, space in the directory name |
| 22:07:20 | gour | windows? |
| 22:07:25 | gradha | so the problem is the vim plugin not escaping it correctly |
| 22:07:35 | gradha | mac |
| 22:07:55 | * | gour never uses spaces in files/dirs |
| 22:09:05 | gradha | you should live a more dangerous life, I even use unicode chars in some paths when I feel lucky |
| 22:10:15 | * | gour likes: "better safe than sorry" |
| 22:10:40 | gradha | says so a sid/testing user... |
| 22:11:35 | gour | testing is not side, it's quite stable...ubuntu packages are based on unstable, testing is just prior to stable |
| 22:11:40 | gour | *sid |
| 22:11:55 | gradha | so that would be half safe half sorry? |
| 22:12:15 | gour | no, safe & happy |
| 22:12:35 | gour | present testing is going to be next stable |
| 23:07:55 | * | NimBot_ joined #nimrod |
| 23:12:14 | * | gour quit (Quit: WeeChat 0.3.8) |
| 23:13:55 | * | gradha quit (Quit: gradha) |