| 01:16:03 | * | q66 quit (Quit: Quit) |
| 05:14:00 | * | reactormonk joined #nimrod |
| 07:02:32 | * | reactormonk quit (Ping timeout: 265 seconds) |
| 08:37:49 | * | fowl quit (Quit: Leaving) |
| 09:32:04 | * | Araq_ joined #nimrod |
| 09:32:49 | * | q66 joined #nimrod |
| 10:01:43 | * | zahary joined #nimrod |
| 11:43:59 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]) |
| 12:39:09 | * | Araq_ joined #nimrod |
| 12:53:27 | * | |apriori| joined #nimrod |
| 12:53:42 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]) |
| 13:10:11 | * | Araq_ joined #nimrod |
| 13:12:14 | Araq_ | hi |apriori| |
| 13:12:22 | Araq_ | so how's progress on BSD? |
| 13:13:44 | |apriori| | Araq_: mediocre |
| 13:14:03 | |apriori| | got no clue yet, why the linker gcc command keeps failing |
| 13:14:12 | |apriori| | and manual execution of the very same command works |
| 13:14:57 | Araq_ | you should compile with --useFork |
| 13:15:02 | Araq_ | er |
| 13:15:05 | Araq_ | -d:useFork |
| 13:16:19 | |apriori| | Araq_: no change, when using koch boot -f -d:release -d:useFork |
| 13:18:02 | |apriori| | as said.. I assume its something build environment related |
| 13:18:25 | Araq_ | ok try --parallelBuild:1 instead |
| 13:18:45 | Araq_ | well I'm not yet out of ideas ;-) |
| 13:18:55 | |apriori| | results in a hang |
| 13:20:00 | |apriori| | http://pastebin.com/aXVZUKp2 |
| 13:20:02 | Araq_ | yay ... |
| 13:20:35 | Araq_ | I think it's not hanging |
| 13:20:41 | Araq_ | but just slow ;-) |
| 13:20:45 | |apriori| | yup.. butt slow |
| 13:21:03 | Araq_ | and doesn't output GCC's progress |
| 13:21:13 | |apriori| | what the hell does it actually do? |
| 13:21:16 | |apriori| | building twice? |
| 13:21:24 | |apriori| | it shows some output like "iteration 1"... "iteration 2" |
| 13:21:39 | |apriori| | funny enough.. the link command succeeded in iteration 1 |
| 13:22:25 | |apriori| | http://pastebin.com/Gq8RpsFt |
| 13:26:33 | |apriori| | there's got to be a race condition somewhere |
| 13:27:17 | |apriori| | when installing the resulting nimrod compiler and using it build a sample app, it failed with: http://pastebin.com/iDJzrRwN |
| 13:27:21 | Araq_ | it builds 3 times |
| 13:27:24 | |apriori| | another invocation of the compiler worked, though |
| 13:28:24 | Araq_ | well add --parallelBuild:1 to your config |
| 13:28:52 | Araq_ | it's a bug that that causes output captchuring to not work ... |
| 13:29:40 | Araq_ | I'll take a look at this code again but for now I consider the issue solved :P |
| 13:29:50 | |apriori| | :P |
| 13:29:54 | |apriori| | ok |
| 13:33:12 | |apriori| | Araq_: and btw, os.getAppFileName() works properly |
| 13:33:34 | |apriori| | but I guess, you know that, since you said, the compiler depends on it anyway |
| 13:34:44 | Araq_ | well I know it worked with my freeBSD version ;-) |
| 13:34:52 | |apriori| | ok ;) |
| 13:34:52 | Araq_ | and I know it doesn't work on NetBSD |
| 13:34:57 | |apriori| | interesting |
| 13:37:52 | Araq_ | traditional UNIX considers it evil if a process knows its full path ... |
| 13:38:16 | |apriori| | that's somewhat paranoid |
| 13:39:13 | Araq_ | *shrug* traditional unix is absurd anyway |
| 13:45:47 | * | Araq_ quit (Read error: Connection timed out) |
| 13:47:45 | * | Araq_ joined #nimrod |
| 13:51:13 | |apriori| | what is wrong about this code?: http://pastebin.com/CCgQLu9n error: http://pastebin.com/Amp4fyGi |
| 13:54:24 | Araq_ | sorry connection problems |
| 13:54:30 | Araq_ | and I have to go anyway |
| 13:54:34 | |apriori| | ok, np |
| 13:54:41 | Araq_ | use the 'pure' or 'final' pragma for your objects |
| 13:55:01 | Araq_ | I think it triggers a known codegen bug ;-) |
| 13:55:07 | |apriori| | okay |
| 13:55:09 | |apriori| | gonna try |
| 13:55:18 | Araq_ | that I should have fixed months ago :-/ |
| 13:55:31 | Araq_ | but there are always better things to do ... |
| 13:56:19 | |apriori| | yeah.. |
| 13:56:26 | |apriori| | especially with this whether right now ;) |
| 13:56:36 | |apriori| | ohm, weather |
| 13:57:09 | Araq_ | bye |
| 13:57:24 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]) |
| 14:19:29 | * | zahary quit (Quit: Leaving.) |
| 14:20:00 | * | zahary joined #nimrod |
| 14:46:30 | * | Trix[a]r_za is now known as Trixar_za |
| 14:49:45 | * | reactormonk joined #nimrod |
| 15:42:56 | * | shevy quit (Read error: Operation timed out) |
| 15:58:39 | * | shevy joined #nimrod |
| 16:54:38 | * | Trixar_za is now known as Trix[a]r_za |
| 17:09:13 | |apriori| | Araq: are you back? |
| 17:09:35 | Araq | |apriori|: yes |
| 17:09:56 | |apriori| | well, there must really be either: 1) a codegen issue 2) some subtle error in my code |
| 17:10:19 | |apriori| | because when debugging, I end up calling storeAux with a ptr TNimNode of nil |
| 17:10:30 | |apriori| | which results in a crash when it gets derefenced |
| 17:14:00 | |apriori| | http://pastebin.com/GAeTffKV |
| 17:16:07 | |apriori| | changing to a ref type in the thread proc doesn't quite change anything |
| 17:17:13 | * | XAMPP joined #nimrod |
| 17:17:13 | * | XAMPP quit (Changing host) |
| 17:17:13 | * | XAMPP joined #nimrod |
| 17:21:51 | Araq | well I think it's a codegen issue |
| 17:22:04 | Araq | create a bug report please |
| 17:22:22 | Araq | as a workaround you could try a tuple |
| 17:34:42 | |apriori| | okay |
| 17:35:39 | |apriori| | same error with a tuple |
| 17:35:50 | Araq | now that's strange |
| 17:36:01 | Araq | still on BSD? |
| 17:36:05 | |apriori| | yes |
| 17:37:05 | Araq | edit system/alloc.nim:20 please |
| 17:37:27 | Araq | and set it to true on bsd |
| 17:37:50 | |apriori| | same error |
| 17:38:07 | Araq | ugh |
| 17:38:24 | Araq | you use --tlsEmulation:on right? |
| 17:38:33 | |apriori| | wait a sec |
| 17:38:40 | |apriori| | you said that is set implictly |
| 17:38:41 | |apriori| | checking |
| 17:39:14 | |apriori| | according to cfg, it should be used |
| 17:39:19 | Araq | ok |
| 17:52:32 | * | ekselkiu joined #nimrod |
| 17:53:10 | ekselkiu | What does "non-tracing garbage collector" mean on http://nimrod-code.org/? |
| 17:55:23 | ekselkiu | According to the docs, Nimrod uses "deferrent reference counting with cycle detection", and the cycle detection. What's "non-tracing" about the cycle detection part? |
| 17:57:49 | Araq | alright alright it does traces cycles ;-) |
| 17:57:56 | Araq | but only the subgraphs that changed |
| 17:58:32 | Araq | and you have lots of control over it |
| 17:58:38 | Araq | but I have to go, see you later |
| 17:58:46 | ekselkiu | OK, thanks. |
| 18:06:44 | dom96 | |apriori|: Out of curiosity, why are you using BSD? What kind of advantages does it offer over say Linux? |
| 18:07:53 | |apriori| | well, currently for me a very specific one: the nvidia drivers work here, whereas they don't on linux |
| 18:07:58 | ekselkiu | I'd probably be using BSD on the desktop right now if it didn't require a primary partition all to itself. |
| 18:08:21 | |apriori| | I got a somewhat strange laptop here... and nvidia seems uncapable of resolving the issue on linux for over a year now |
| 18:08:52 | |apriori| | that forced me to an ancient version of the driver and Xorg... a workaround that no longer works, because now applications/windowsmanagers get dependant on changes in later Xorg versions |
| 18:09:25 | ekselkiu | What changes? |
| 18:09:41 | |apriori| | as a interesting side effect.. a project I develop at university is running a hell lot faster on bsd than on linux - for whatever reason |
| 18:09:43 | ekselkiu | Or at least, changes in which subsystems? |
| 18:09:49 | |apriori| | I dont quite now |
| 18:10:00 | |apriori| | I just run into very early segfaults I can't really debug |
| 18:10:10 | ekselkiu | O_o |
| 18:10:11 | |apriori| | they reside in libGL, after passing through Xorg |
| 18:10:42 | |apriori| | the nvidia drivers replace major parts of Xorg with their own... so that is expected |
| 18:11:14 | |apriori| | and since that libGL is closed source, I got no clue where the issue is |
| 18:11:35 | |apriori| | I could just disassemble it.. something I don't quite wanna do |
| 18:11:45 | ekselkiu | Understandably ^_^ |
| 18:11:51 | |apriori| | dom96: about other advantages: |
| 18:12:08 | |apriori| | bsd is more conservative and doesn't join usual hype trains early on |
| 18:13:29 | dom96 | I certainly never heard anyone say that BSD works for them but Linux doesn't. Interesting. |
| 18:15:45 | dom96 | Last time I tried setting up FreeBSD(IIRC) it seemed quite complicated, and well I failed even to set up the network. |
| 18:16:13 | |apriori| | dom96: I use a slightly modified variant, called PC-BSD |
| 18:16:20 | |apriori| | under the "hood" its plain FreeBSD |
| 18:16:31 | |apriori| | but, yeah, the installer even there is a pain |
| 18:16:39 | |apriori| | it required quite some manual intervention |
| 18:17:47 | dom96 | I wonder if anyone ever tried to create something like Arch Linux but for BSD |
| 18:17:50 | |apriori| | dom96: and I don't quite know what exactly is causing the issue... |
| 18:18:05 | ekselkiu | I just got rather annoyed that FreeBSD wouldn't install in a logical partition. |
| 18:18:10 | |apriori| | the fun part is just, that the driver "thinks" the card gets removed from the bus when running |
| 18:18:28 | |apriori| | dom96: you mean rolling release? |
| 18:18:40 | |apriori| | I very much doubt that.. it's quite contrary to the philosophy |
| 18:18:58 | |apriori| | you can stay bleeding edge in FreeBSD.. but then you have to build things using ports yourself |
| 18:19:21 | dom96 | |apriori|: Sure. But also the awesome arch wiki, the easy (well... for programmers I suppose) installation ... and pacman. |
| 18:19:36 | |apriori| | the "easy" installation is history.. |
| 18:19:43 | |apriori| | if you took a look at the latest changes |
| 18:19:57 | |apriori| | the installation now is more gentoo-like |
| 18:20:27 | |apriori| | and, yeah, I like arch a lot though (with the exception of introducing systemd) |
| 18:21:25 | dom96 | Are you talking about the removal of AIF? |
| 18:21:44 | |apriori| | of what? |
| 18:22:00 | dom96 | The Arch Installation Framework. |
| 18:22:03 | |apriori| | yup |
| 18:22:18 | |apriori| | now its not really hard either... but definetly harder than before |
| 18:22:33 | dom96 | I see. I haven't had a chance to see how it differs. |
| 18:22:35 | |apriori| | but you know your way around, if you ever used a livecd to mount your existing installation |
| 18:23:00 | |apriori| | and.. I completely hate grub 2 |
| 18:23:21 | |apriori| | and its completely bloated cfg files, it does need now for even simple use cases |
| 18:23:29 | |apriori| | and that all, because one wanted to remove stage_1_5 |
| 18:25:40 | dom96 | Yeah, many people stopped using grub once Arch forced grub2 on them. |
| 18:25:58 | dom96 | I personally didn't have any problems with it. |
| 18:26:30 | |apriori| | well, with grub1 I could write the complete menu file without having a look at any manual... |
| 18:26:36 | |apriori| | that is simply impossible with grub2 |
| 18:27:03 | |apriori| | in which you pretty much need to do everything by hand.. load file system modules etc. |
| 18:27:31 | dom96 | Isn't there a tool which automatically detects the OS' you have installed and generates everything for you? |
| 18:28:33 | dom96 | I guess it doesn't help you if you need more control though |
| 18:29:25 | |apriori| | os prober? |
| 18:29:28 | |apriori| | didn't quite work for me |
| 18:31:06 | dom96 | interesting. In PC-BSD all apps are installed into /programs |
| 18:33:01 | |apriori| | dom96: not quite true |
| 18:33:17 | |apriori| | PC-BSD does have 2 systems |
| 18:33:32 | |apriori| | the "appcafe" (or hell, I hate the word "app" so much, but nvm) |
| 18:33:41 | |apriori| | which installs using the pbi system into /usr/pbi |
| 18:33:54 | |apriori| | and ports + pkg, which use the usual FreeBSD locations |
| 18:36:14 | dom96 | oh |
| 18:40:42 | shevy | hmmm wait |
| 18:40:45 | shevy | the /usr/pbi |
| 18:40:50 | shevy | what is that equivalent to? /usr/local ? |
| 18:40:56 | |apriori| | nope |
| 18:41:14 | shevy | ok asked differently, what is in /usr/pbi ? for instance? |
| 18:41:15 | |apriori| | in /usr/pbi each application is installed under its own directory |
| 18:41:21 | shevy | ah ok so |
| 18:41:28 | shevy | gcc would be in /usr/pbi/gcc ? |
| 18:42:44 | |apriori| | http://pastie.org/4495156 |
| 18:43:19 | shevy | chromium-amd64 claws-mail-amd64 konversation-amd64 yakuake-amd64 |
| 18:43:20 | shevy | hmm ok |
| 18:43:22 | shevy | so it is |
| 18:43:30 | shevy | name_of_package-architecture |
| 18:43:38 | shevy | but only 4 directories there hmmm |
| 18:43:48 | |apriori| | because the rest is installed using ports + pkg |
| 18:44:21 | * | Amrykid_ joined #nimrod |
| 18:44:58 | * | Amrykid quit (Disconnected by services) |
| 18:45:02 | * | Amrykid_ is now known as Amrykid |
| 18:45:10 | * | Amrykid quit (Changing host) |
| 18:45:11 | * | Amrykid joined #nimrod |
| 18:45:31 | |apriori| | also each pbi has some file called .auto-external-links |
| 18:45:40 | |apriori| | which names files to be symlinked into the usual unix file base |
| 18:45:45 | |apriori| | or dir base |
| 18:47:22 | |apriori| | to me, it seems to create an overlay |
| 18:48:59 | shevy | aha |
| 18:49:53 | shevy | yeah |
| 18:49:59 | shevy | quite a lot how gobolinux handles it |
| 18:50:12 | shevy | compile into i.e. /Programs/Htop/1.0.1 then symlink this into /System/Links |
| 18:50:25 | shevy | when other version, like /Programs/Htop/1.0.2, resymlink |
| 18:50:58 | |apriori| | yeah, although I don't quite see those symlinks |
| 18:52:27 | |apriori| | ok, now things get really weird |
| 18:52:38 | |apriori| | seeing a bunch of different files in e.g. /usr/pbi/konversation/bin |
| 18:52:44 | |apriori| | seems more like a hardlink to somewhere else |
| 18:54:32 | |apriori| | oh, oh... |
| 18:54:36 | |apriori| | "The PBI format tries to correct this underlying flaw. Rather than making every application a part of the base system, PBIs are self-contained, including their own dependent library tree and related data. As a result, when you install a PBI there are no dependency issues to resolve, and applications can be added or removed freely, without fear of causing breakage to the desktop or any other installed software." |
| 18:56:03 | ekselkiu | Never mind. I didn't want to store anything other than redundant libraries on my hard disk anyway. |
| 18:56:34 | |apriori| | Filesystem Size Used Avail Capacity Mounted on |
| 18:56:35 | |apriori| | /dev/label/rootfs0 24G 14G 7.4G 67% / |
| 18:56:37 | |apriori| | O_o |
| 18:57:29 | ekselkiu | What distro is this? GobbleLinux? :D |
| 18:57:37 | |apriori| | PC-BSD |
| 18:57:39 | ekselkiu | Oh. |
| 18:57:43 | |apriori| | guess, I gonne get rid of PBI |
| 18:57:50 | shevy | gobolinux does not store dependencies in the same directory |
| 18:58:02 | shevy | every program, without exception, will always reside in /Programs/NAME_HERE/VERSION_HERE |
| 18:58:13 | shevy | including Glibc! |
| 18:58:21 | shevy | but I never managed to upgrade glibc on my own :P |
| 18:58:45 | |apriori| | well, that actually makes more sense than the extreme waste of space due to having hundreds of times the same lib installed |
| 18:58:52 | shevy | hmm |
| 18:59:02 | shevy | I think the idea might have been to use .pbi and distribute them freely, like on USB sticks and so on |
| 18:59:20 | |apriori| | I don't quite now |
| 18:59:41 | |apriori| | one should rather have a multi-version control of all libs centralized in the system |
| 18:59:54 | |apriori| | instead of having each application ship their own junk with them |
| 19:00:52 | |apriori| | and that "just delete the application to get rid of it all" can be solved with simple reference counting |
| 19:01:16 | ekselkiu | Or dedupe at the file-system level. |
| 19:01:34 | |apriori| | yeah.. another approach |
| 19:02:16 | |apriori| | I actually also don't quite get it... |
| 19:02:28 | |apriori| | if I see it correctly, that auto links file tries to do exactly that |
| 19:02:43 | |apriori| | guess I need to ask the filesystem, whether its not simple fooling me |
| 19:02:48 | |apriori| | *simply |
| 19:02:54 | shevy | hehe |
| 19:19:43 | Araq | arg, now it's even 2 of you ... |
| 19:19:52 | Araq | why can't you just let BSD die? :P |
| 19:21:40 | |apriori| | Araq: muhahaha ;) |
| 19:21:56 | |apriori| | shevy: well, I was fooled.. |
| 19:22:07 | |apriori| | pbi shares files between packages using hardlinks |
| 19:23:21 | Araq | why oh why do I have to support 4 OSes for my 3 users ... |
| 19:23:41 | shevy | because they may together recruit ONE MORE USER in 3 months |
| 19:23:45 | shevy | using Haiku |
| 19:23:46 | shevy | HAHAHA |
| 19:24:39 | dom96 | Araq: Because I want my apps to run on EVERYTHING |
| 19:25:03 | |apriori| | dom96: I would second that... |
| 19:25:07 | |apriori| | though its definetly impossible |
| 19:25:24 | |apriori| | Araq: and who dares to run a mac, here? :P |
| 19:25:34 | dom96 | yeah, well I am not being serious. However, it would be nice to support as much as we can. |
| 19:25:58 | Araq | I think zahary and q66 both do use a mac ... |
| 19:26:04 | dom96 | That said I am happy as long as the "big 3" are supported. |
| 19:26:14 | shevy | linux, linux and |
| 19:26:15 | shevy | linux |
| 19:26:36 | dom96 | shevy: :) |
| 19:26:44 | q66 | linsux, winblows and mac osux |
| 19:26:54 | shevy | haha |
| 19:26:59 | dom96 | Araq: ddl_smurf still runs his builder, count him in too ;) |
| 19:27:07 | q66 | and FreeLSD |
| 19:27:13 | |apriori| | Araq: and, correct me if I'm wrong.. but my bug isn't really FreeBSD-dependant, is it? |
| 19:27:26 | Araq | he only runs it when I improve idetools support ... |
| 19:27:42 | Araq | which means he's happy with everything else already :P |
| 19:27:52 | Araq | |apriori|: let me check ... |
| 19:27:56 | dom96 | Araq: Really? The builder fails though |
| 19:28:10 | dom96 | Sometimes I wonder if he's even aware it's running |
| 19:28:13 | q66 | |apriori| and yes, i'm running OS X right now, u butthurt bro? |
| 19:28:26 | dom96 | Maybe he made it autostart and sometimes he switches on his Mac and doesn't even notice :P |
| 19:28:28 | |apriori| | q66: butthurt bro? |
| 19:28:37 | q66 | i'm also running FreeBSD and arch/debian |
| 19:29:13 | |apriori| | q66: question was, what you're actually "using".. not developing for |
| 19:29:39 | q66 | right now i'm using OS X on this computer and laptop |
| 19:29:40 | dom96 | We need to support Macs unfortunately. Too many of them on the desks of JPL employees during the Curiosity landing. |
| 19:29:40 | |apriori| | and.. frankly.. I tend to have a bad impression about people saying mac os is actually useful (besides some niches) |
| 19:29:53 | q66 | it's not a bad OS |
| 19:30:23 | Araq | it is :P |
| 19:30:26 | |apriori| | the os base is quite solid.. the framework thingy (the variant of libs)/dynlib is brain damaged |
| 19:30:33 | Araq | it even lies about its bitwidth |
| 19:30:43 | q66 | frameworks kinda suck, yeah |
| 19:30:53 | Araq | uname -a ... wtf? |
| 19:31:02 | q66 | what about uname -a |
| 19:31:08 | Araq | it lies |
| 19:31:15 | q66 | huh how |
| 19:31:21 | q66 | Darwin q66.local 12.0.0 Darwin Kernel Version 12.0.0: Sun Jun 24 23:00:16 PDT 2012; root:xnu-2050.7.9~1/RELEASE_X86_64 x86_64 |
| 19:31:24 | q66 | seems quite correct to me |
| 19:31:37 | Araq | oh they finally fixed that? |
| 19:31:46 | |apriori| | q66: and I hate apples philosophy so much... |
| 19:31:55 | q66 | |apriori|, which is? |
| 19:32:03 | Araq | try uname -m please |
| 19:32:07 | * | ekselkiu quit (Quit: My friend has a low IQ and anorexia, but I stuck with him through thick and thin.) |
| 19:32:09 | q66 | i like how OS X just works, linux could learn from that |
| 19:32:19 | |apriori| | like maintaining only "big" updates.. including graphics drivers. a friend of mine has to buy a complete upgrade of his os in order to get up to date drivers supporting newer opengl versions |
| 19:32:21 | q66 | Araq, x86_64 |
| 19:32:30 | Araq | alright so they finally fixed it |
| 19:32:36 | |apriori| | q66: totally agreed on that.. on the "just works" side, linux definetly sucks |
| 19:33:43 | q66 | |apriori|, also, only "big" updates? all the minor OS upgrades as well as security updates etc are free |
| 19:33:48 | dom96 | If Linux had a big company like Apple behind I'm sure it would be much better. |
| 19:33:48 | q66 | you buy only new version of the OS |
| 19:33:54 | dom96 | It might even "just work" |
| 19:34:03 | |apriori| | q66: might be.. but in that case, that didnt include his damn graphics drivers. |
| 19:34:14 | dom96 | And be dumb-proof like Windows, which is enough for most people. |
| 19:34:18 | |apriori| | and that is kinda ridiculous |
| 19:34:23 | q66 | |apriori|, tbh, opengl on OS X sucks, yes |
| 19:34:34 | q66 | it doesn't support GL3.x compatibility profile and it doesn't support GL4.x |
| 19:34:38 | dom96 | *behind it |
| 19:34:48 | |apriori| | q66: yup, had much fun with that |
| 19:34:59 | |apriori| | although..the most fun definetly was to get brain damaged dynlibs working |
| 19:35:12 | |apriori| | mac os doesn't have a proper rpath (neither has windows) |
| 19:35:25 | q66 | i don't have a problem with dylibs, i have a problem with lack of --export-dynamic in ld :p |
| 19:35:46 | |apriori| | so one had to manually alter the libs (don't recall the tools name) @executable_path or something like that.. |
| 19:35:47 | q66 | the symbols are exported by default, but when you strip the binary you lose them |
| 19:35:49 | q66 | that's just silly |
| 19:35:58 | |apriori| | and that had to include even absolute paths.. silly beyond imagination |
| 19:36:37 | Araq | IMHO the lack of proper thread local storage support is a show stopper |
| 19:36:37 | q66 | imo the OSes all have pros and cons; i'm using them pretty much all |
| 19:36:43 | |apriori| | yeah, I guessI ran into very weird special cases |
| 19:36:58 | |apriori| | q66: sure |
| 19:37:09 | |apriori| | but what I definetly hate most about apple is: hype |
| 19:37:10 | q66 | as well as develop for them all |
| 19:37:23 | q66 | |apriori|, what I hate about apple is fanboys |
| 19:37:26 | Araq | the posix api is a very poor workaround for __thread |
| 19:37:27 | q66 | their OS and hw is solid |
| 19:37:40 | q66 | and i hate iOS toys |
| 19:37:46 | |apriori| | q66: same here.. the university project I was working on ran on win, linux (32 and 64), freebsd (32, 64) and mac |
| 19:37:53 | |apriori| | although not really required.. |
| 19:38:24 | |apriori| | q66: I in general hate fanboys :P |
| 19:38:25 | q66 | my game engine runs on windows, linux, freebsd, mac, solaris, possibly some others, on 32 and 64 bits for all. |
| 19:38:44 | |apriori| | ah.. now I remember.. |
| 19:38:48 | |apriori| | you are that game engine dev of #D |
| 19:38:55 | q66 | i don't really use D though |
| 19:39:08 | q66 | anymore |
| 19:39:15 | |apriori| | pretty much same here... |
| 19:39:28 | |apriori| | I mean.. (kudos to you, Araq).. |
| 19:39:34 | |apriori| | compared to nimrod its developing slowly |
| 19:39:42 | Araq | thanks |
| 19:39:44 | Araq | but lol |
| 19:39:51 | q66 | D is immature involving bad design decisions some of which they consider good |
| 19:40:03 | Araq | nimrod's development is slow too |
| 19:40:03 | |apriori| | Araq: indeed, LOL... considering the man power |
| 19:40:05 | q66 | and they can't prioritize |
| 19:40:16 | |apriori| | q66: I so agree here |
| 19:40:27 | |apriori| | e.g. not getting the base right.. like the GC |
| 19:40:29 | q66 | the best way to get a feature in D is to rant about it on reddit; you can be pretty sure it'll be in in a week. :P |
| 19:40:33 | |apriori| | and the flaws with "shared" |
| 19:41:01 | Araq | the Ada guys had a good description of it though it was a quote from reddit I think: |
| 19:41:13 | q66 | |apriori|, those aren't even the biggest problems of D, but yes, they are annoying |
| 19:41:16 | Araq | this is a feature list, not a design :P |
| 19:41:23 | |apriori| | Araq: const correctness? |
| 19:41:29 | q66 | IMO their perception of "safety" is completely wrong |
| 19:41:32 | |apriori| | oh well, q66, I meant |
| 19:41:35 | q66 | they take it as a "feature" |
| 19:41:51 | |apriori| | yeah, maybe... |
| 19:42:09 | Araq | they confuse "safety" with "wishful thinking" ... |
| 19:42:17 | q66 | that results in broken "safe" code when it has to interact with regular unsafe code |
| 19:42:26 | |apriori| | Araq: apropos safety.. |
| 19:42:41 | q66 | the language should be safe by default with explicit unsafe, because interacting with safe code from unsafe code is fine, the other way it becomes difficult |
| 19:42:42 | |apriori| | one thing I _really_ liked in D was the unittest() block statement |
| 19:42:47 | |apriori| | although its limited... |
| 19:43:12 | Araq | |apriori|: check the unittest module |
| 19:43:20 | q66 | also their perception of safety is dangerously close to that of C++ |
| 19:43:54 | |apriori| | q66: you still didn't explain "butthurt bro" |
| 19:43:59 | q66 | generally, it tries to take C++ features and improve over them, but when the originals are broken, nothing can be improved |
| 19:44:00 | |apriori| | q66: correct |
| 19:44:11 | q66 | wm4 called it "polishing a turd" and he was right |
| 19:44:52 | q66 | |apriori|, as for that, i was basically poking at you for the "<|apriori|> Araq: and who dares to run a mac, here? :P" |
| 19:45:08 | |apriori| | Araq: am I blind or isn't it documented anywhere? |
| 19:45:22 | |apriori| | q66: okay ;) |
| 19:45:39 | q66 | what's good about D is the community, it's generally helpful and nice without being assholes like those around C++ |
| 19:45:51 | |apriori| | agreeing on that, too |
| 19:46:02 | |apriori| | I totally hate the arrogance in #c++ |
| 19:46:12 | q66 | it's not only the arrogance |
| 19:46:34 | q66 | they're also pedantic |
| 19:46:53 | Araq | |apriori|: true it's not documented :P |
| 19:47:08 | q66 | and they don't seem to live in real world with their UB rants |
| 19:47:28 | q66 | also criticism results in instant ban |
| 19:48:00 | |apriori| | q66: no rare known abbrevs plz :P |
| 19:48:03 | |apriori| | UB? |
| 19:48:06 | Araq | funny thing is: you can't program in it without triggering some kind of UB |
| 19:48:08 | q66 | undefined behavior, |apriori| |
| 19:48:15 | |apriori| | ah, k |
| 19:48:24 | |apriori| | Araq: right |
| 19:48:24 | q66 | C++ is full of them, so is C |
| 19:48:35 | q66 | they still seem to have some kind of hate against UB, while they love C++ to death |
| 19:48:40 | |apriori| | actually... you just add barriers around UB |
| 19:48:42 | q66 | even through all of its retarded corner cases |
| 19:49:07 | |apriori| | yeah.. but progressing with language rant |
| 19:49:20 | q66 | there's a nice C++ channel around on efnet |
| 19:49:22 | |apriori| | I don't like javas overstatement of "OOP over everything" either |
| 19:49:33 | q66 | people there generally aren't as retarded as on freenode and quakenet |
| 19:49:44 | q66 | but it has exceptions as well |
| 19:50:14 | |apriori| | well, expections have their issues as well |
| 19:50:24 | |apriori| | like.. breaking problem locality etc. |
| 19:50:32 | q66 | i wasn't talking about exceptions :p |
| 19:50:39 | |apriori| | oh, well |
| 19:50:44 | |apriori| | I'm slow today :) |
| 19:50:45 | q66 | i was talking about that efnet's C++ chan is generally nice with some exceptions. |
| 19:51:12 | Araq | |apriori|: indeed the bug is not related to BSD ... |
| 19:51:17 | q66 | that doesn't mean I like exception handling, though; I think the cost of them is generally too big considering the little benefit they provide |
| 19:52:21 | |apriori| | the problem is.. well, you might get free error state traversal, but you will also get hard return value/error state disconnections |
| 19:52:43 | |apriori| | I'd even prefer that to be in the type system, in form of an Either/MayBe type |
| 19:52:45 | q66 | <|apriori|> I don't like javas overstatement of "OOP over everything" either |
| 19:52:46 | q66 | as for this |
| 19:52:53 | q66 | there are OO systems that are fine |
| 19:52:56 | q66 | java's is not one of them :P |
| 19:53:18 | q66 | mainly using OO as sole paradigm is silly; it only works in combination with something or in specific case |
| 19:53:29 | |apriori| | well, I get into touch with java enterprise at work.. I never spent so much time not solving my actual problem. |
| 19:53:33 | q66 | and the class+interface+instance+factory-based system of Java is crap |
| 19:54:09 | q66 | I'm a fan of simple prototype systems as shown by Io, Lua or Self |
| 19:54:17 | |apriori| | well, I once really liked OOP... but changed my mind, when I realized, how often it results in absolutely bloated hierarchies with completely unneeded expressional power |
| 19:54:57 | q66 | |apriori|, you were doing OOP wrong |
| 19:54:58 | q66 | :p |
| 19:55:07 | |apriori| | maybe |
| 19:55:25 | q66 | it's not about using it everywhere, it's about using it where feasible |
| 19:55:37 | |apriori| | try that with java :P |
| 19:55:43 | q66 | i.e. it makes total sense with a widget toolkit |
| 19:56:00 | |apriori| | yeah, I think, I learned that with the university project, I mentioned |
| 19:56:06 | q66 | you can specify widget tree hierarchies representing your UI using objects |
| 19:56:06 | |apriori| | a physics simulation software... |
| 19:56:20 | q66 | and it's a lot less tedious than doing it procedurally for example like in C |
| 19:56:39 | |apriori| | OOP for the gui stuff + task type management .. normal procedural style for the actual simulation |
| 19:57:32 | q66 | in my game engine i have an UI system written entirely in Lua; it uses a combination of object system (a custom hybrid prototype+instance-based) with functional/procedural features |
| 19:57:36 | |apriori| | q66: apropos "tedious":. take a look at the official OpenCL C api :P |
| 19:57:56 | q66 | it's basically complete, simple, with nice interface, integrates well, isn't hidden under layers of abstraction |
| 19:58:11 | q66 | and takes less than 4k lines for basically complete set with everything |
| 19:58:16 | |apriori| | written from scratch? |
| 19:58:18 | q66 | yes |
| 19:58:25 | |apriori| | yeah, that's quite some work |
| 19:58:36 | q66 | uses opengl to draw |
| 19:58:38 | |apriori| | and so is a game engine in general |
| 19:58:51 | q66 | |apriori|, i consider opengl api nice |
| 19:58:53 | |apriori| | that's why I never started such a project.. it would take years to get somewhere |
| 19:59:06 | |apriori| | q66: Open_C_L |
| 19:59:10 | q66 | oh |
| 19:59:15 | q66 | haven't worked with opencl much |
| 19:59:34 | q66 | but i like opengl for being low level; you can bind it to any language in an evening |
| 19:59:35 | |apriori| | and now khronos introduced computer shaders into OpenGL... |
| 19:59:42 | q66 | it's just primitives |
| 19:59:46 | |apriori| | yeah, agreed.. |
| 20:00:04 | |apriori| | you need a C API as base to get binding to other languages in a non-nightmarish way |
| 20:00:31 | q66 | C as a language is obsolete now, but it's a standard for interoperability |
| 20:00:44 | |apriori| | well, I don't think its obsolete |
| 20:00:52 | q66 | |apriori|, for non-low level stuff |
| 20:00:53 | |apriori| | it will remain low-level..for decades, I guess |
| 20:00:59 | |apriori| | yeah, agreed on that |
| 20:01:12 | Araq | it's obsolete thanks to Nimrod's --os:standalone switch :P |
| 20:01:15 | q66 | though, I tend to write high level C code from time to time |
| 20:01:28 | q66 | mainly when doing code for Enlightenment |
| 20:01:29 | |apriori| | Araq: what does that do? |
| 20:01:35 | |apriori| | Araq: use its own backend? |
| 20:01:35 | Araq | which strips away everything and makes nimrod a nicer syntax for C |
| 20:01:49 | Araq | quite the opposite |
| 20:02:03 | Araq | strips away Nimrod's stdlib and everything |
| 20:02:10 | |apriori| | ah, k |
| 20:02:17 | |apriori| | and about nicer syntax for C .. definetly |
| 20:02:22 | Araq | so that you can use it to develop your own kernel |
| 20:02:24 | |apriori| | and.. I can't say it often enough |
| 20:02:29 | |apriori| | I fucking love the tuple support |
| 20:02:35 | Araq | :-) |
| 20:02:54 | q66 | i like Rust |
| 20:02:58 | q66 | it's awesome emerging language |
| 20:03:17 | |apriori| | got no real oppinion about it.. |
| 20:03:18 | Araq | q66: I'd like to design a UI that doesn't use OO but closures heavily instead |
| 20:03:22 | |apriori| | never use it.. only saw trivial examples |
| 20:03:30 | q66 | Araq, my UI technically uses closures |
| 20:03:45 | q66 | because Lua's OO is associative arrays with closures :P |
| 20:03:57 | Araq | true |
| 20:04:15 | q66 | tbh, I often use nested closure hierarchies in Lua, it's often very convenient |
| 20:04:26 | q66 | but for the UI OO proved better |
| 20:04:37 | Araq | damn ;-) |
| 20:04:55 | q66 | after learning Lua there is one thing I miss in many languages |
| 20:04:59 | q66 | true first class functions. |
| 20:05:43 | q66 | where you can simply return a function, pass a function, assign it to a variable .. where a named function is nothing else but a variable with funciton value. |
| 20:06:34 | Araq | Nimrod now supports that ;-) |
| 20:06:37 | q66 | along with Lua's tables and metatables and the fact every function is a closure with transparent upvalues it makes it a very powerful language albeit minimal |
| 20:07:04 | Araq | afaict closures are stable now |
| 20:07:14 | q66 | Araq, are they true garbage collected closures? |
| 20:07:21 | Araq | yes sir |
| 20:07:21 | q66 | or fake ones like in C++ :P |
| 20:07:38 | Araq | well since we have a true GC ... :P |
| 20:08:32 | q66 | Araq, c++ won't allow this http://codepad.org/1Vk9Spe7 |
| 20:08:35 | q66 | so it's fake :P |
| 20:09:27 | q66 | cool nimrod has true ones, though. |
| 20:09:30 | Araq | take a guess ... I'm quite aware of these subtle semantic differences ;-) |
| 20:09:33 | q66 | more languages need true closures |
| 20:10:05 | Araq | IMO no true callback system can be built without them |
| 20:10:14 | q66 | and no proper iterator system |
| 20:10:23 | Araq | I disagree |
| 20:10:39 | q66 | well, you can also do it with coroutines. :P |
| 20:10:46 | Araq | iterators are not closure based, they are coroutine based, yes |
| 20:10:56 | q66 | but closures are good for this too. |
| 20:11:02 | q66 | and less costly, too |
| 20:13:20 | q66 | Araq, like http://codepad.org/9irNLmSs |
| 20:13:28 | q66 | equivalent, first one is faster |
| 20:13:52 | Araq | not in nimrod ;-) |
| 20:14:52 | q66 | how so? you need to copy the stack with coroutines |
| 20:15:07 | q66 | or at least some of it anyway |
| 20:15:29 | Araq | well in this simple case you can use nimrod's iterators which use an inlining implementation |
| 20:15:54 | q66 | well i'm not talking about a specific simple case, i'm doing a comparison in general |
| 20:16:05 | q66 | closures should be faster in principle |
| 20:16:39 | q66 | of course, for this exactly i can do for i = 5, 10 do .... :P |
| 20:16:44 | q66 | and it'll be teh fastest |
| 20:16:53 | q66 | except with luajit where it'll be equivalent |
| 20:17:06 | Araq | luajit is annoying |
| 20:17:29 | q66 | luajit is great, but reading its code gives me headaches |
| 20:17:37 | Araq | as it takes away one good reason for static typing ;-) |
| 20:18:02 | q66 | static typing is cool, dynamic typing is cool, as long as you use both appropriately |
| 20:18:05 | Araq | he he, I have been reading luajit's source code too |
| 20:18:20 | Araq | and at least I understand some things ;-) |
| 20:18:36 | Araq | whereas haskell's compiler is a single big WTF? :D |
| 20:19:01 | q66 | yeah, i worked with luajit source as well, initially it's quite cryptic |
| 20:19:14 | q66 | but one can figure stuff out eventually |
| 20:19:28 | q66 | the biggest problem is to determine what comes from what :P |
| 20:19:49 | q66 | as some stuff is macros stuffed in some header etc |
| 20:19:59 | q66 | and grep usually gives multiple pages of output |
| 20:30:06 | Araq | btw rust is indeed nice but I noticed they are throwing away their "type state" system ;-) |
| 20:30:48 | Araq | and IMO immutability is superficial in a systems programming language |
| 20:31:06 | Araq | mutable state is an important optimization |
| 20:32:48 | Araq | the rust code I skimmed is full of 'let mu' :-) |
| 20:42:08 | q66 | Araq, rust is a high level language too. |
| 20:42:26 | q66 | I like that Rust doesn't have unconstrained null |
| 20:42:38 | Araq | yeah that's really good |
| 20:42:55 | Araq | it's hard to do for nimrod though |
| 20:43:08 | Araq | as the language still lacks a notion of a constructor |
| 20:44:06 | Araq | my plan is to support arbitrary predicates as types |
| 20:44:35 | q66 | I also like how it integrates various functional stuff into a procedural language; like pattern matching and type classes |
| 20:45:26 | Araq | true but not suprising as the compiler was first written in ocaml |
| 20:47:03 | q66 | it's also not suprising the compiler was first written in ocaml as ocaml is a good language for writing it. |
| 20:52:39 | Araq | true but for Nimrod's AST pattern matching doesn't help much |
| 20:52:50 | Araq | so I sticked with pascal |
| 20:53:12 | Araq | the foreign function call syntax didn't help either ;-) |
| 20:56:13 | reactormonk | Araq: as long as it's not APL, you shouldn't have a problem with syntax. |
| 20:56:45 | Araq | it was 2004 or something when I decided about an implementation language |
| 20:56:55 | Araq | Pascal won as I already was familiar with it |
| 20:57:02 | Araq | had a good debugger |
| 20:57:19 | Araq | is dead easy to parse and thus to translate into nimrod |
| 20:57:23 | |apriori| | pascal was the first language I used... |
| 20:57:43 | Araq | and I already had lots experience in it |
| 20:57:51 | Araq | and writing lexers and parsers in it |
| 20:57:56 | Araq | so ocaml lost ;-) |
| 20:58:13 | dom96 | Araq: So you considered ocaml? Interesting. |
| 20:58:25 | Araq | indeed I did |
| 20:59:05 | dom96 | When I look at pascal code I can really see how close it is to Nimrod :P |
| 20:59:35 | Araq | true but modula 3 is pretty close too :P |
| 21:01:26 | Araq | iirc I considered Lua, Python, Pascal/Delphi, ML and Ocaml for an implementation language |
| 21:03:22 | Araq | Lua and Python lost due to lack of a 'case' statement ;-) |
| 21:04:30 | dom96 | hehe. |
| 21:05:30 | Araq | Lua is also very error prone |
| 21:05:39 | Araq | oh, something is nil, interesting |
| 21:06:00 | Araq | glad it propagates like NaN through the data flow |
| 21:06:21 | Araq | oh, a typo in the field name ... fun, fun, fun |
| 21:06:38 | reactormonk | Araq: wasn't that what static checking is for? |
| 21:07:12 | Araq | indeed but Lua has none |
| 21:07:19 | dom96 | I'm surprised you considered Lua at all |
| 21:07:34 | Araq | first version of pas2nim was in Lua ... |
| 21:07:41 | Araq | crazy, hu? |
| 21:09:02 | dom96 | :O |
| 21:09:09 | dom96 | I don't believe it |
| 21:09:18 | Araq | but it's true |
| 21:09:45 | Araq | it started as a script that did some simple replacements |
| 21:09:57 | Araq | line based iirc |
| 21:10:47 | Araq | it got ever more complex until I wanted a real parser |
| 21:11:51 | Araq | and then I threw it away and wrote a pascal parser in pascal for pas2nim |
| 21:45:25 | * | Trix[a]r_za is now known as Trixar_za |
| 21:54:51 | dom96 | Araq: So. Are we shooting for 0.9.0 this weekend? |
| 21:55:20 | Araq | hrm no |
| 21:55:32 | Araq | too many annoying bugs left and some features missing |
| 21:55:42 | Araq | 0.9.0 when I have holidays |
| 21:56:05 | Araq | the bug |apriori| found is downright embarrassing |
| 21:56:48 | dom96 | Alright. Gives me more time to perfect Aporia then |
| 21:57:10 | Araq | get rid of that "double click opens new tab" feature please |
| 21:57:17 | Araq | it's incredibly annoying |
| 21:57:32 | dom96 | Who requested that feature? |
| 21:57:42 | dom96 | Was it Filwit? |
| 21:57:47 | Araq | dunno |
| 21:57:54 | Araq | make it optional then |
| 21:58:19 | dom96 | I think I will have to rework the settings dialog soon |
| 21:58:40 | dom96 | It will become hard to find settings pretty soon |
| 21:59:20 | Araq | that's why you should just show some text file instead |
| 21:59:33 | Araq | show the configuration file instead |
| 21:59:45 | Araq | --> search for free |
| 22:00:06 | Araq | scite does it this way |
| 22:00:10 | Araq | and I just love it |
| 22:00:25 | Araq | because it makes so much sense |
| 22:00:41 | Araq | it's a *text editor* after all |
| 22:01:09 | |apriori| | Araq: did you actually isolate the cause, yet? |
| 22:01:44 | Araq | |apriori|: looks like a recently introduced bug, haven't looked into it |
| 22:01:51 | dom96 | Araq: Yes, but it's a GUI text editor. |
| 22:01:55 | Araq | I'm breaking code instead |
| 22:02:12 | dom96 | I'll consider it though |
| 22:02:26 | |apriori| | Araq: ok... |
| 22:02:34 | Araq | is it important? |
| 22:02:39 | |apriori| | Araq: just to make sure.. no need to rush.. I know I can be enerving :D |
| 22:03:13 | Araq | implementing new features is more fun :P |
| 22:03:23 | |apriori| | yeah, I know that... |
| 22:03:31 | |apriori| | happened to me in game dev, too.. |
| 22:03:53 | Araq | I try my best to fix bugs before releasing a new version though |
| 22:03:55 | |apriori| | some issues became 2 years old.. but were so damn incredibly hard to fix with only limited access to the game engine :/ |
| 22:04:18 | Araq | in fact, I try to keep bug count below 25 |
| 22:04:34 | Araq | as then I have a single page to look at on github |
| 22:07:00 | |apriori| | btw., out of curiosity.. which haskell compiler did you mean with the big "WTF"? |
| 22:07:01 | |apriori| | ghc? |
| 22:07:13 | |apriori| | meant you, Araq |
| 22:07:20 | Araq | yeah, tried to read its source code once |
| 22:07:45 | |apriori| | okay |
| 22:13:58 | Araq | so any experience with D's const system, |apriori| ? |
| 22:14:13 | |apriori| | Araq: not too good ones, yes |
| 22:14:35 | Araq | my humble opinion is that it's not worth the complexity |
| 22:14:38 | |apriori| | I think it's incredibly hard to get it right |
| 22:15:24 | |apriori| | well, in a way you already have what java has |
| 22:15:31 | |apriori| | final and non-final.. and that's it |
| 22:16:03 | |apriori| | with var and non-var, I mean |
| 22:16:32 | |apriori| | though one apparently can't use them in generics, it seems? |
| 22:17:00 | Araq | what do you mean? 'var T' is certainly possible |
| 22:17:33 | |apriori| | yeah, well, forget it.. that was the special case of that actorpool |
| 22:18:00 | |apriori| | the workerthread function must not have the prototype proc (var Tin) {.thread.} |
| 22:18:01 | Araq | alright |
| 22:18:20 | Araq | well yeah and there are reasons for it |
| 22:18:27 | Araq | you can use 'ptr T' though |
| 22:18:44 | |apriori| | ok |
| 22:18:49 | Araq | and in fact I would use that as message passing is incredibly slow otherwise |
| 22:19:11 | |apriori| | any specific reasons why? |
| 22:19:29 | Araq | 'ptr T' does no deep copy |
| 22:19:31 | |apriori| | I saw you used (apparently) rtti in the rawSend code |
| 22:19:41 | Araq | yeah |
| 22:19:43 | |apriori| | might that be a reason for the peformance issues? |
| 22:19:55 | Araq | exactly that's one problem |
| 22:20:12 | Araq | the other is that deep copying is required |
| 22:20:22 | |apriori| | hm |
| 22:20:24 | Araq | because of Nimrod's GC per thread design |
| 22:20:35 | Araq | but there are ways around it ;-) |
| 22:20:44 | |apriori| | ah, so when passing over to another thread..it deep copies for the instance to be handled by the other gc, ok |
| 22:21:21 | Araq | in fact, it copies twice |
| 22:21:32 | |apriori| | I'm not quite into all that.. but couldn't a ownership transfer work? |
| 22:21:39 | |apriori| | well, I guess it wont.. one would have to lock both for that |
| 22:21:48 | Araq | he he yes |
| 22:21:52 | Araq | I thought hard about it |
| 22:22:04 | Araq | and asked other GC writers |
| 22:22:12 | Araq | nobody had a better solution |
| 22:22:29 | |apriori| | btw., when using only value types. am I right the gc is never used? |
| 22:22:32 | reactormonk | Araq: why do you have 'final' at all btw? |
| 22:22:54 | |apriori| | reactormonk: its not exactly final |
| 22:22:55 | Araq | |apriori|: that is correct |
| 22:23:18 | |apriori| | reactormonk: you either have normal type or "var type", with var being mutable in the block |
| 22:23:19 | Araq | reactormonk: the question is "why do I have inheritance at all? :P |
| 22:23:25 | |apriori| | :P |
| 22:23:54 | |apriori| | Araq: that might be explain, why that shootout port even outperformed C.. :P |
| 22:24:13 | |apriori| | god damn.. my english get's weaker.. :P |
| 22:25:11 | Araq | |apriori|: true but nimrod's GC is faster than FPC's memory allocator I think |
| 22:25:21 | |apriori| | oh, ok |
| 22:27:37 | Araq | er no, screw that |
| 22:27:42 | Araq | http://forum.nimrod-code.org/t/27 |
| 22:27:46 | Araq | doesn't say that |
| 22:28:28 | Araq | but there is still room for improvement for the GC and it's designed for predictability anyway |
| 22:28:47 | Araq | raw throughput is not its aim |
| 22:29:38 | Araq | though it beats boehm's GC for the nimrod compiler itself |
| 22:29:57 | |apriori| | yeah, predictability is way more important |
| 22:30:02 | |apriori| | e.g. for games.. |
| 22:30:05 | Araq | which is harder than it sounds as boehm uses all of my cores ... |
| 22:30:27 | Araq | whereas my GC is single threaded :P |
| 22:31:02 | |apriori| | not bad |
| 22:31:26 | |apriori| | but .. developing several multithread algos myself.. I know, how quickly one can run into what I call "synchronisation hell" |
| 22:32:05 | |apriori| | in which the management of the threads etc. becomes so expensive, tha it totally wipes out any benifit of having multithreading at all |
| 22:32:19 | |apriori| | the bad thing about that.. its often not really predictable :/ |
| 22:32:25 | Araq | yeah that's a hard problem |
| 22:32:43 | Araq | in my tests the GC never missed a deadline of 2ms :P |
| 22:32:52 | |apriori| | good :) |
| 22:32:58 | Araq | and the tests weren't friendly to it |
| 22:33:05 | |apriori| | even better |
| 22:33:14 | Araq | for a game 1ms should be easy to achieve |
| 22:33:29 | |apriori| | well, somebody should try ^^ |
| 22:33:35 | Araq | yeah ... |
| 22:34:16 | |apriori| | I've considered using nimrod for my next university project (seminar, raytracing on gpus).. but I doubt I will have enough time for it |
| 22:34:29 | |apriori| | an implementation is not needed.. and would be "for fun" |
| 22:34:37 | Araq | hm pity |
| 22:34:38 | |apriori| | but there'd be a lot of basic stuff to implement |
| 22:35:19 | |apriori| | yeah.. severe lack of time is an issue :P |
| 22:35:43 | dom96 | good night guys |
| 22:35:53 | |apriori| | night, dom96 |
| 22:36:17 | Araq | by dom96 |
| 22:48:44 | Araq | I have to sleep too |
| 22:48:46 | Araq | good night |
| 22:49:14 | |apriori| | night, Araq |
| 23:07:06 | shevy | pfft |
| 23:07:13 | shevy | when he sleeps, there is no new code into nimrod |
| 23:07:17 | shevy | we need a japanese contributor |
| 23:07:17 | shevy | :P |
| 23:09:05 | |apriori| | lol |
| 23:09:25 | |apriori| | I think he already is quite fast |
| 23:09:47 | |apriori| | and highly motivated... like.. you come naming an error.. "I will fix that some day".. 1 day later "fixed" |
| 23:09:54 | |apriori| | you see several examples of that just in the forums |
| 23:15:35 | shevy | yeah |
| 23:34:07 | * | XAMPP quit (Ping timeout: 246 seconds) |
| 23:35:27 | |apriori| | gonna get some sleep, too |
| 23:35:28 | |apriori| | bye |
| 23:35:36 | * | |apriori| quit (Remote host closed the connection) |
| 23:37:09 | * | XAMPP joined #nimrod |