00:02:51 | * | q66 quit (Quit: Quit) |
04:15:31 | * | fowl joined #nimrod |
04:17:43 | * | comex quit (Excess Flood) |
04:28:57 | * | comex joined #nimrod |
04:28:58 | * | comex quit (Excess Flood) |
05:40:56 | * | comex joined #nimrod |
05:40:57 | * | comex quit (Excess Flood) |
05:41:09 | * | comex joined #nimrod |
05:41:55 | * | comex quit (Excess Flood) |
05:42:03 | * | comex joined #nimrod |
05:42:24 | * | comex quit (Excess Flood) |
05:43:50 | * | comex joined #nimrod |
07:18:51 | * | Boscop quit (Ping timeout: 256 seconds) |
09:05:52 | * | fowl quit (Read error: Connection reset by peer) |
09:51:25 | * | Trix[a]r_za is now known as Trixar_za |
10:12:00 | * | ccssnet quit (*.net *.split) |
10:12:00 | * | JStoker quit (*.net *.split) |
10:15:38 | * | ccssnet joined #nimrod |
10:15:38 | * | JStoker joined #nimrod |
10:20:38 | * | rking quit (*.net *.split) |
10:20:40 | * | XAMPP quit (*.net *.split) |
10:22:06 | * | XAMPP joined #nimrod |
10:22:06 | * | rking joined #nimrod |
10:23:24 | * | zahary quit (*.net *.split) |
10:24:03 | * | zahary joined #nimrod |
10:25:37 | * | XAMPP quit (*.net *.split) |
10:26:51 | * | XAMPP joined #nimrod |
12:05:29 | * | Trixar_za is now known as Trix[a]r_za |
12:37:45 | * | Boscop joined #nimrod |
13:00:07 | * | Araq_ joined #nimrod |
13:13:50 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]) |
13:22:47 | * | q66 joined #nimrod |
17:32:48 | * | AraqInTrouble joined #nimrod |
17:36:04 | * | AraqInTrouble quit (Client Quit) |
17:43:55 | * | araq_bnc joined #nimrod |
17:54:24 | * | araq_bnc quit (Quit: ChatZilla 0.9.89 [Firefox 9.0.1/20111220165912]) |
17:54:39 | * | Araq is now known as araq_bnc |
17:56:31 | * | araq_bnc is now known as Araq |
17:57:02 | Araq | so ... the trouble is over ;-) |
17:59:10 | dom96 | AraqInTrouble heh. Sounds like you're unable to talk and you're instead simply giving us an SOS using your nick hah |
17:59:52 | Araq | yeah |
17:59:56 | Araq | if that happens again |
18:00:02 | Araq | check our server is still running :P |
18:37:56 | * | comex quit (Excess Flood) |
18:40:53 | * | comex joined #nimrod |
18:40:55 | * | comex quit (Excess Flood) |
18:41:41 | * | comex joined #nimrod |
18:53:12 | * | comex quit (Quit: Coyote finally caught me) |
18:53:21 | * | comex joined #nimrod |
19:03:47 | * | gradha joined #nimrod |
19:04:03 | Araq | yay, gradha |
19:04:09 | gradha | yay me |
19:04:35 | Araq | has been a bit silent the last days here ;-) |
19:05:46 | gradha | not much nimrod to talk about? |
19:05:54 | gradha | I saw the tag commit recently |
19:06:30 | gradha | I'm thinking a perverted way of tacking system calls might be for the compiler to auto-generate a tag with the name of the proc and a prefix |
19:06:46 | gradha | then the doc command strips the prefix and says "this proc calls these other procs" |
19:06:53 | gradha | not pretty, but seems doable |
19:07:45 | Araq | maybe but what's the point? |
19:08:07 | gradha | no point, just chatting, to fill the irc logs |
19:08:19 | Araq | alright :-) |
19:09:19 | Araq | btw I looked over your example code |
19:10:19 | gradha | calculator or todo? |
19:11:30 | Araq | and somewhere you should use a string case instead of an if-statement |
19:11:30 | Araq | there were other things, let me see |
19:11:30 | Araq | ah yes: I don't really like every single 'import' on its own line |
19:11:31 | Araq | well I don't mind it either |
19:11:31 | Araq | but you wanted more feedback |
19:11:32 | Araq | echo("page " & $page) # --> |
19:11:40 | Araq | echo "page ", page |
19:11:43 | Araq | (todo) |
19:12:14 | gradha | cool, this is what I was writing while you started: "so what's the definitive style for echo. Is it like python's print, that everybody uses without parenthesis, then comes a new version and forces them?" |
19:13:55 | Araq | the "command call" syntax is very common in nimrod |
19:14:27 | gradha | it's slightly confusing to have some calls with parenthesis and some not |
19:14:27 | Araq | it's not a special case for 'echo' |
19:14:27 | Araq | and you'll never see me making petty things like that |
19:14:47 | gradha | it sort of breaks when you try to use the oo sugar syntax with dot |
19:14:53 | Araq | yeah but if anything even more calls will get rid of the () |
19:14:59 | Araq | how does it break? |
19:15:09 | Araq | result.add xyz # works fine |
19:15:20 | gradha | I remember having trouble with the todo example and putting parenthesis to help the compiler |
19:15:23 | gradha | or maybe my mind |
19:15:30 | Araq | the problem is this: |
19:15:33 | Araq | echo $xyz |
19:15:37 | Araq | as it's parsed as: |
19:15:45 | Araq | echo $ xyz # binary $ |
19:16:18 | Araq | there are some ideas of turning nimrod into a "whitespace surrounding operators" sensitive language |
19:16:40 | gradha | reads like claustrofobia |
19:16:40 | Araq | so that 4+5 * 3 would have the precedence that the whitespace suggests |
19:16:57 | gradha | that's interesting |
19:17:11 | gradha | it will be confusing as hell to an outsider, though |
19:17:20 | Araq | it's suprisingly simple to implement :P |
19:17:41 | Araq | but yeah maybe it's too revolutionary ;-) |
19:18:06 | reactormonk | gradha, why? I would expect echo $xyz to be parsed as echo($(xyz)) and echo $ xyz as $(echo, xyz) |
19:18:10 | gradha | count me in for revolution |
19:18:32 | gradha | reactormonk: I don't have handy the lines which were giving me problems |
19:18:49 | gradha | maybe it's just that I was struggling with the language itself and confused the compiler error messages |
19:19:03 | gradha | happened twice when I was changing from ref TTodo to just TTodo |
19:19:20 | gradha | maybe the problem was the lack of auto-defering |
19:19:34 | gradha | I'll just comb through the example again and see how it goes this time |
19:21:01 | gradha | Araq: the reason I like separate imports is because I always sort them alphabetically, so I get to find them faster if needed, and also reduces diff pollution in source control |
19:21:17 | gradha | but then, I'm biased by C's #include |
19:21:49 | gradha | oh, the good old rule of including stuff from local to external modules to detect dependencies and reduce include hell |
19:25:04 | Araq | alright but why do you need to find them? |
19:25:23 | Araq | for me they are mostly compiler nanny'ing |
19:25:36 | gradha | removing/adding code, especially when refactoring |
19:25:49 | gradha | I dislike leaving a lot of #include cruft behind |
19:25:55 | Araq | aha |
19:25:57 | gradha | not sure if its an issue with nimrod |
19:26:05 | * | Araq never removes unused imports ;-) |
19:26:08 | gradha | well well well |
19:26:13 | gradha | since we are talking about stuff |
19:26:23 | gradha | why not a compiler switch which tells what imports are useless? |
19:27:11 | gradha | would that help with compilation speed using big wrappers like gtk? |
19:27:48 | Araq | not really |
19:27:59 | Araq | since gtk is split up in very few modules |
19:28:59 | Araq | a compiler switch about unused imports sounds simple to do though |
19:30:06 | gradha | I recall github posting something on their blog that you can hint at coding style guides when somebody does a pull request, can't find it though |
19:30:28 | gradha | it could be good to add these nitpicks to that guide, at least would free you from repeating them to other people too |
19:31:19 | Araq | dunno the only thing that I really despise is whitespace before ':' ;-) |
19:31:31 | * | apriori_ joined #nimrod |
19:31:51 | Araq | in fact, I thought about making that a compilation error |
19:32:09 | Araq | and whitespace before ; or , for that matter |
19:32:40 | Araq | speaking of which ... your code contains ' :' :P |
19:32:49 | gradha | still? I thought I got rid of it |
19:33:01 | Araq | testbackend.nim line 61 |
19:33:29 | gradha | indeed |
19:34:04 | gradha | looks like an editing mistake, first using a var block, then getting rid of other variables, joining in a line and forgetting that space |
19:34:32 | gradha | so what's keeping you from adding a git commit hook to detect these? |
19:34:32 | Araq | TCommand = enum # The possible types of commands |
19:34:33 | Araq | commandAdd ... |
19:35:03 | gradha | odd indentation there |
19:35:06 | Araq | I try to avoid learning about git ;-) |
19:35:19 | Araq | my point is: there are now 'pure' enums |
19:35:33 | Araq | so instead of prefixing every enum member with 'command' |
19:35:46 | Araq | you can skip the prefix and use TCommand.Add instead |
19:36:06 | gradha | nice, didn't know that |
19:36:19 | gradha | I recall copying that structure from somewhere, maybe tools subdirectory |
19:36:38 | gradha | didn't pay much attention on how it was used, though |
19:36:57 | Araq | well 'pure' for enums is quite new |
19:37:20 | Araq | and I like the 2-3 char prefixes better ;-) |
19:38:21 | Araq | this System.Text.Regex.X stuff is a disease IMHO |
19:39:03 | gradha | so the dot notation is only when there's a namespace conflict |
19:39:19 | Araq | most of the time, yes |
19:39:31 | Araq | sometimes I use it for clarity |
19:39:57 | gradha | maybe commandAdd would be CAdd |
19:40:24 | gradha | commandCheck -> CCheck, commandList -> CList, etc |
19:40:28 | gradha | reminds me of MFC |
19:40:46 | Araq | http://nimrod-code.org/apis.html suggests it should be cmdAdd |
19:41:17 | gradha | cmdAdd will be then |
19:45:07 | Araq | btw why do we need an sqlite database for a todo store? ;-) |
19:45:21 | reactormonk | just because |
19:45:30 | gradha | it's to exercise the module |
19:45:35 | reactormonk | it's a standard for storing data. Why reinvent the wheel :-P |
19:45:47 | Araq | the forum runs on sqlite ... |
19:45:55 | Araq | no need to test it :P |
19:46:17 | reactormonk | Araq, not too much traffic? |
19:46:31 | gradha | my preferred way would have been to use a json file, but I just happened to crash against db_sqlite first |
19:46:33 | Araq | it used to use postgre but I got tired of postgre's complex setup |
19:47:18 | Araq | changing the backend mostly required to change the imports :P |
19:47:24 | Araq | and of course bits of the sql |
19:47:44 | Araq | somehow the lack of a common interface with dynamic binding was no problem :P |
19:49:22 | Araq | and yeah reactormonk, we have not much traffic because people stop using the forum once they found the index :P |
19:49:23 | gradha | talking about storing files, nowadays I just piggyback on json libraries, but in the good old days I used to write bits and bytes manually |
19:49:31 | gradha | how would that be accomplished in nimrod? |
19:50:03 | reactormonk | gradha, strings and write |
19:50:18 | Araq | there are a couple of procs that can write via an untyped pointer |
19:50:20 | gradha | so you build a buffer in memory and blast it? |
19:50:36 | Araq | you can go as low level as C |
19:50:46 | Araq | requires an unsafe 'cast' though |
19:51:53 | gradha | I have plans to wrap an old C IO library for packing/unpacking data, so maybe I should just rewrite it in nimrod |
19:52:10 | Araq | no need for a manual rewrite |
19:52:14 | Araq | use c2nim for that |
19:52:48 | Araq | you still need to tweak your C heavily for c2nim |
19:52:56 | Araq | but it's much better than rewriting it by hand |
19:53:09 | gradha | I'll keep that in mind when the time comes |
19:55:58 | dom96 | IIRC fowl wrote something for working with bits and bytes, he used it for sockets but I don't see why it wouldn't work for writing files too. |
19:59:15 | * | ekselkiu joined #nimrod |
20:11:29 | gradha | I don't mind writing cmdAdd, but the type for the enum, TCommand, feels better without compression |
20:12:12 | Araq | I'm not suggesting that *my* style is nimrod's style guide |
20:12:40 | gradha | isn't nimrod your creation? |
20:12:44 | Araq | in fact, for an example I suggest to use TCommand.Add too |
20:13:04 | Araq | nimrod is my creation, yes |
20:13:14 | Araq | but I'm dirtier than Nimrod :P |
20:13:28 | gradha | my 1st rule of contributing is mimicking the style of the author |
20:13:36 | gradha | I actually won't be using it in my own code |
20:14:44 | gradha | you see, I'm from_the_lower_case_mentality |
20:15:24 | Araq | recent papers suggest this_is_really_more_readable thanThis |
20:15:52 | Araq | so I guess you're right :P |
20:16:13 | gradha | only for 50% of the word right |
20:16:28 | gradha | well, much less if we consider all the variations of each style |
20:20:07 | Araq | oh apriori_, forgot to tell you |
20:20:28 | Araq | please put your OS kernel on github |
20:24:15 | apriori_ | Araq: will do that |
20:24:24 | apriori_ | although... |
20:24:40 | apriori_ | some part of that is pretty much 100% of my professor.. will ask him whether he has something against it |
20:25:06 | Araq | your professor programmed it in nimrod? ;-) |
20:25:58 | apriori_ | nope |
20:26:01 | apriori_ | the asm part |
20:26:04 | apriori_ | the bootloader etc. |
20:26:34 | Araq | hrm ... |
20:27:11 | reactormonk | Araq, reference? |
20:27:38 | Araq | reference for what? |
20:28:21 | reactormonk | Araq, snake_case vs. CamelCase |
20:29:55 | gradha | awww, the case insensitivity rule expectedly breaks at the import level |
20:30:06 | gradha | can't import dbSqlite |
20:31:22 | gradha | poking stuff is fun, reminds me of spectrum times |
20:33:41 | Araq | hu? |
20:33:51 | Araq | that should work ... |
20:34:10 | Araq | the compiler tries an all lowercase version then |
20:34:13 | gradha | let me try again and see if I had dreamt it |
20:34:19 | Araq | ah but it doesn't insert the '_' |
20:34:27 | Araq | ;-) |
20:35:12 | gradha | just case would be sort of expected, at least since some of the platforms are case insensitive for filenames |
20:36:15 | Araq | reactormonk: http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ |
20:36:25 | Araq | http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf |
20:39:04 | Araq | but IMO this argument trumps everything else: "Camel case makes *paragraphs* easier to read." |
20:39:47 | gradha | only if you write your paragraphs without spaces between words? |
20:40:25 | gradha | I find that line pretty offensive by itself, in both styles |
20:41:05 | Araq | well reading a program is all about layout and thus "paragraphs" |
20:41:37 | Araq | add spaces and it's still easier to read with camelCase |
20:41:55 | Araq | I tried it recently with a 5 line GTK example :P |
20:43:12 | gradha | having worked with both styles more or less equally I find it hard to point one style easier to read or the other |
20:43:34 | gradha | so for me it's just preference when writing, but reading I don't mind |
20:45:28 | * | fowl joined #nimrod |
20:46:57 | gradha | you don't have papers on kpop vs jpop? still can't make my mind on that |
20:47:14 | Araq | GtkWidget *scrolledWindow = gtk_scrolled_window_new(NULL, NULL); |
20:47:16 | Araq | gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrolledWindow), |
20:47:18 | Araq | GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); |
20:47:20 | Araq | gtk_container_add(GTK_CONTAINER(scrolledWindow), GTK_WIDGET(webView)); |
20:47:21 | Araq | vs. |
20:47:54 | Araq | GtkWidget *scrolledWindow = gtkScrolledWindowNew(NULL, NULL); |
20:47:56 | Araq | gtkScrolledWindowSetPolicy(GtkScrolledWindow(scrolledWindow), |
20:47:57 | Araq | GtkPolicyAutomatic, GtkPolicyAutomatic); |
20:47:59 | Araq | gtkContainerAdd(GtkContainer(scrolledWindow), GtkWidget(webView)); |
20:48:19 | Araq | sucks in both versions but I find the later easier to read |
20:48:29 | gradha | for me the first |
20:48:37 | Araq | because I can tokenize it way more easily |
20:48:54 | fowl | imo the first one is better |
20:49:04 | Araq | I guess it's because I don't really read those long identifiers anyway ;-) |
20:49:10 | Araq | they are offensive |
20:49:20 | gradha | in fact you could nitpick it should have been scrolled_window and web_view |
20:49:46 | gradha | certainly mixing styles is the worst, unless done for a reason |
20:49:51 | fowl | oh yea i started writing a wrapper for horde3d http://www.horde3d.org/ |
20:50:00 | gradha | like interfacing with an existing library in another language |
20:50:28 | Araq | fowl: that's nice but are the other wrappers finished? ;-) |
20:51:42 | fowl | >_> im getting to them i swear |
20:56:43 | gradha | Araq: situation were parenthesis are needed, calling a proc without parameters |
20:56:58 | gradha | but it's fine when using dot syntax, like input,parseInt |
20:57:36 | gradha | so, the first time you encounter that it feels odd that calling the proc without parenthesis doesn't work, because the return is the proc itself |
20:57:53 | gradha | until you reason that the dot syntax is actually reversing the words into parseInt something |
20:58:23 | Araq | sorry, I can't follow you |
20:58:37 | Araq | what's the concrete example? input.parseInt ? |
20:58:46 | Araq | input.parseInt() works too |
20:59:03 | gradha | the failing part is writing "var p = initOptParser" |
20:59:07 | gradha | that requires the parenthesis |
20:59:15 | gradha | otherwise you assign the proc to p |
20:59:19 | gradha | rather than calling it |
20:59:41 | gradha | and that's why it looks confusing at first when you compare it to input.parseInt |
20:59:55 | gradha | you think "why can I call parseInt without parenthesis but not initOptParser?" |
21:00:09 | gradha | and depending on how long your gears start turning it could get frustrating |
21:00:45 | Araq | aha, interesting |
21:00:57 | Araq | can't be fixed easily though |
21:01:09 | Araq | first order functions are too cool :P |
21:01:56 | gradha | another situation might be "case normalize inputString" |
21:02:14 | gradha | though I guess you can case inputString.normalize |
21:02:24 | gradha | yep |
21:03:03 | Araq | 'case normalize inputstring' may become valid though |
21:03:17 | gradha | so you see, it just feels odd that you get free of all parenthesis, and later find out you still have to put some |
21:03:39 | fowl | moonscript uses the ! postfix for calling a func wtih no args |
21:03:39 | Araq | p() vs p is pretty essential though |
21:03:57 | Araq | how does that improve anything? |
21:04:19 | fowl | its shorter than () :> |
21:05:05 | Araq | it also conflicts with the rest of nimrod's grammar :P |
21:14:24 | Araq | apriori_: just claim it's your asm code, a professor doesn't mind to put his name under any work done by his students either |
21:14:39 | gradha | ok, found a non parenthesis code which I don't know why it fails |
21:15:06 | gradha | https://github.com/Araq/Nimrod/blob/master/examples/cross_calculator/nimrod_commandline/nimcalculator.nim#L96 |
21:15:21 | gradha | If I remove the parenthesis to the parseUserInput call it doesn't compile |
21:15:26 | gradha | but I'm not sure why |
21:16:05 | Araq | it's because you can leave out () in dot notation or if it's a statement |
21:16:20 | Araq | it's neither in your example, so it doesn't work |
21:16:32 | gradha | ah, so it will never work in a let/var block then |
21:16:41 | Araq | you can do: parseUserInput"Enter ..." though ;-) |
21:16:54 | gradha | yuck |
21:17:16 | gradha | yuck? |
21:17:42 | gradha | is that a special case for strings which can be used in other places too? |
21:18:09 | gradha | oh, that feels so evil |
21:18:23 | Araq | yeah, it's an "extended string literal" |
21:22:44 | gradha | is there any situation where the language allows not writing parenthesis but you still put them or do you go to the extreme? |
21:23:33 | Araq | I often use () when they're not needed |
21:23:41 | Araq | result.add("xyz") |
21:30:57 | gradha | before continuing a pull request take a look at https://github.com/gradha/Nimrod/commit/f2aa171867fca139c8422ab551d6af29bb19e3e7 and see if that is something you prefer or not |
21:31:03 | gradha | it's going to the extreme removing () |
21:31:58 | gradha | oh, you can even mark the individual lines you don't like, amazing what this html5 stuff can do nowadays |
21:38:32 | Araq | well your changes are fine with me |
21:38:42 | Araq | may confuse people though |
21:38:53 | Araq | they could try to leave out () everywhere :P |
21:39:33 | gradha | hehe, isn't that the point then? |
21:40:53 | gradha | I'll comb the todo example too then in similar fashion |
21:41:13 | Araq | in fact |
21:41:26 | Araq | you should work on something more useful instead :P |
21:41:32 | Araq | the examples are fine the way they are |
21:41:55 | Araq | for instance, the stdlib lacks a websockets module |
21:42:10 | gradha | shame I know nothing about websockets |
21:42:26 | gradha | isn't that like fancy html thingy? |
21:42:59 | gradha | I'll leave the examples then... for now |
21:43:13 | Araq | well we also lack a bignum library |
21:43:29 | Araq | I started to port one over from pascal but I won't give you the code |
21:43:39 | Araq | as I figured it has the wrong licence |
21:44:02 | gradha | don't know about bignum either |
21:44:21 | gradha | I have other stuff pending, I will take my time to reach to such levels of contributions |
21:49:50 | Araq | well we also need more wrappers but I think mostly hard wrappers are left to do: |
21:49:57 | Araq | Qt, wxWidgets, webkit |
21:50:55 | gradha | don't know about webkit, qt and wxwidgets have really left a bad taste for me writing and maintaining software for them |
21:51:02 | gradha | what would be the purpose of webkit? |
21:51:08 | gradha | isn't that like an html render engine? |
21:51:17 | Araq | yeah |
21:51:30 | gradha | you plan to write a browser in nimrod then? |
21:52:12 | gradha | if forced to do it I would first try fltk, despite not being able to compile the mac version last time I tried |
21:52:28 | apriori_ | gradha: its not only to write a feature complete browser |
21:52:30 | gradha | seems much smaller and easier to tackle |
21:52:43 | apriori_ | take it as a more convenient way to embedd html rendering into a gui application |
21:53:10 | gradha | at least that's interesting |
21:53:10 | Araq | a browser engine is nice for writing a crawler ;-) |
21:53:11 | apriori_ | well, I worked a bit on getting a Qt wrapper working back in #D.. its .. sorry to say it.. a pain in the ass |
21:53:25 | Araq | it's not |
21:53:36 | gradha | I've programmed Qt in c++ and python, and didn't like either |
21:53:37 | apriori_ | then I doubt you know Qt that well :P |
21:53:43 | Araq | there is a freepascal wrapper for Qt 4, translate that |
21:53:48 | apriori_ | hrm |
21:53:53 | apriori_ | interesting... |
21:54:12 | apriori_ | the D wrapper used the QtJambi class generator and modified it to create D classes instead of java classes |
21:55:12 | gradha | Araq: sorry about the modules but I have an agenda at the moment, it involves going mobile |
21:55:43 | Araq | gradha: np, just don't use any other programming language ever again if you can help it ;-) |
21:55:59 | gradha | well, just today I had to use java |
21:56:19 | gradha | but I'll be working on making nimrod my primary language |
21:57:44 | gradha | anything but java |
21:58:05 | apriori_ | dont get me started on java again ;) |
21:58:45 | gradha | sorry, I believe we have not met previously |
21:59:08 | apriori_ | yup.. I more meant.. we had discussions about java here several times already |
21:59:39 | apriori_ | and the short result is: we hate it :P |
22:00:09 | gradha | indeed |
22:01:05 | apriori_ | gradha: but about qt.. name a better gui toolkit... |
22:01:26 | gradha | uff, haven't like any for some reason or another |
22:01:26 | apriori_ | you won't find many.. maybe wxwidgets, after it completely reworked its API.. but e.g. java swing/awt sucks big time |
22:01:56 | gradha | IIRC wxwidgets was 2.4.x or something like that, was that already rewritten? |
22:02:15 | apriori_ | uff.. dont know the exact point |
22:02:37 | apriori_ | I just got into contact with wxwidgets.. disliked its API.. then looked at it again years later and wondered how close it become to Qt |
22:03:01 | gradha | I think I didn't like it because I found some bugs which nobody cared about and I didn't know well enough to fix them myself |
22:03:35 | apriori_ | you will find the exact same thing in pretty much any project :) |
22:04:00 | gradha | it sort of depends on the complexity and documentation of the code |
22:04:23 | gradha | for instance, the documentation currently for nimrod seems pretty on par with what I saw for wxwidgets, which was terribly lacking |
22:04:39 | gradha | but in theory nimrod is not yet 1.0 |
22:04:46 | gradha | and wxwidgets is 2.xsomething |
22:04:56 | Araq | apriori_: try lazarus then ;-) |
22:04:56 | apriori_ | agreed |
22:04:58 | gradha | that tells me docs aren't their main selling point |
22:05:03 | fowl | id like to do this project in nimrod http://www.gobolinux.org/abstk/ |
22:05:37 | Araq | fowl: know about it, sounds cool |
22:05:39 | gradha | fowl: that reminds me of python anygui |
22:05:56 | gradha | ahaha, yes, anygui died |
22:06:06 | gradha | too many pythonistas in there |
22:06:08 | apriori_ | while it sounds cool.. it will have bad limitations for more complex UI |
22:06:15 | Araq | abstracting the UI tends to produce UIs that I don't want to use though ;-) |
22:06:18 | apriori_ | but it should be absolutely sufficient for config dialog related stuff |
22:06:25 | apriori_ | or something like networkmanager front ends |
22:06:40 | fowl | apriori_: it was only really intended for install wizards |
22:06:59 | fowl | abstk was at least |
22:07:27 | gradha | for text ui I know of http://tvision.sourceforge.net, don't recommend it though |
22:07:38 | gradha | it's designed still around c++ compatibility support problems |
22:08:15 | gradha | and to avoid linking too much cruft the author decided to do some pretty obscure casts |
22:08:24 | gradha | which sort of defeats the purpose of writting oop c++ code |
22:15:28 | dom96 | perhaps Smoke could be used to make Qt bindings? http://techbase.kde.org/Development/Languages/Smoke/API_Documentation |
22:16:28 | Araq | I'd pas2nim the pascal qt wrapper |
22:16:31 | dom96 | From what i've (which is very little currently) it allows C# to have auto-generated bindings which are up-to-date with little effort. |
22:17:47 | apriori_ | the problem with merely ported wrappers is,the binding will hardly inherit any "style" of the target language |
22:18:30 | apriori_ | dom96: and smoke is no real option.. |
22:18:42 | apriori_ | it has massive call overhead, because it constantly looks up huge maps on every call |
22:19:00 | Araq | yeah but pascal is closer to nimrod than C ;-) |
22:19:20 | Araq | so sometimes you get lucky and get a better style |
22:22:03 | Araq | and sometimes you get new bugs ;-) |
22:22:07 | apriori_ | yup |
22:22:56 | * | gradha quit (Quit: gradha) |
22:23:20 | dom96 | It is unfortunate, but a good GUI wrapper will require a lot of maintenance and effort. |
22:23:33 | apriori_ | dom96: yup.. thats the problem with them |
22:23:48 | apriori_ | thats why many language maintainers try to use generators for them |
22:24:19 | apriori_ | e.g. swig (not good either), smoke (written for qt back then, not that good either)... |
22:24:33 | apriori_ | all because of that mess called c++-ABI |
22:24:58 | Araq | actually C is bad enough thanks to the preprocessor and the fucked up declaration syntax |
22:25:21 | apriori_ | well.. I like c++s const declaration syntax, too :P |
22:25:27 | apriori_ | const char* const anyone? :P |
22:25:34 | Araq | which is C now too :P |
22:26:08 | Araq | and it's *important* to know about 'const' in an inherently memory unsafe language :P |
22:26:19 | apriori_ | yup |
22:27:09 | apriori_ | OS dev is fun, too.. btw.... sometimes interrupts get lost in an emulator whereas it might not happen on real hardware |
22:27:30 | Araq | sounds like iPhone development :P |
22:27:31 | apriori_ | that makes writing emulator-proof OSes even more fun |
22:27:55 | Araq | program runs fine in the emulator ... crashes on a real phone ... yay |
22:28:03 | apriori_ | oh.. I learned quite a bit about OS dev now.. and the fucked up design that is the PC architecture... |
22:28:32 | apriori_ | like... access routed over the keyboard controller just to gain access to more than 1MB ram and stuff |
22:29:00 | Araq | :D |
22:29:12 | apriori_ | and well.. interrupts itself... its actually not easy to get it right.. and damn easy to get it wrong |
22:29:18 | apriori_ | no wonder things are buggy.. |
22:29:32 | Araq | so that's where DOS gets its additional memory from ... |
22:30:00 | apriori_ | well.. backward compatibility has some benefits, too... |
22:30:17 | apriori_ | even the most modern xeon processor can run in an 8086 emulation mode |
22:30:32 | Araq | that's good |
22:30:50 | Araq | unfortunately I have no programs for the 8086 .. |
22:30:54 | apriori_ | :P |
22:31:04 | apriori_ | yeah, its not that unimportant, though... |
22:31:19 | apriori_ | because right after the BIOS boots you need some bootloader which is pretty much CPU agnostic |
22:32:08 | Araq | yeah, hardware is easier to change than software ;-) |
22:32:26 | apriori_ | depends :P |
22:35:21 | * | apriori__ joined #nimrod |
22:35:36 | * | apriori__ quit (Client Quit) |
22:35:44 | * | apriori__ joined #nimrod |
22:36:14 | Araq | so when will you create a kickass matrix lib with term rewriting rules for nimrod, apriori_ ? |
22:36:55 | apriori__ | when I have time... |
22:37:16 | Araq | that's an answer |
22:37:18 | apriori__ | minors parts of it are done |
22:37:42 | apriori__ | but I wonder.. term rewriting should be used with caution... |
22:38:18 | apriori__ | e.g. there are plenty of shortcouts to a zero vector in vector arithmetic.. question is.. is that desired to use that? or would one prefer consistent numerical instability? |
22:39:14 | * | apriori_ quit (Ping timeout: 240 seconds) |
22:39:21 | apriori__ | I remember a case, in which a student at my university curses about an AMD cpu "sometimes" doing 80bit floating point arithmetic instead of 64bit, whenever the respective unit was "free".. and that made debugging a nightmare |
22:41:25 | Araq | that's not important, just make it *fast* |
22:41:38 | apriori__ | I will... |
22:42:07 | apriori__ | testing against eigen3 might be useful.. thats a quite worthy competitor |
22:42:49 | Araq | he he, yeah |
22:43:14 | apriori__ | guess I gonna reprioritize then.. just releasing the nimrod kernel.. and continue focusing on getting the matrix lib done |
22:43:22 | apriori__ | losing focus too often ;) |
22:43:32 | Araq | happens |
22:43:47 | Araq | that's why I'm here and giving orders |
22:43:50 | apriori__ | ^^ |
22:44:10 | apriori__ | you got your ironic day, don't you? :P |
22:44:21 | Araq | well I had 3 beer ... |
22:44:32 | apriori__ | and I assume you don't drink that often |
22:44:43 | apriori__ | so you feel quite an impact ^^ |
22:45:04 | Araq | true |
22:45:44 | apriori__ | anyway, gotta go now |
22:45:46 | apriori__ | bye all |
22:45:57 | * | apriori__ quit (Quit: Konversation terminated!) |
23:22:54 | * | ekselkiu quit (Ping timeout: 260 seconds) |