| 02:01:55 | * | q66 quit (Quit: Quit) |
| 07:46:15 | * | gour joined #nimrod |
| 09:41:31 | * | Trix[a]r_za is now known as Trixar_za |
| 09:47:58 | * | gour quit (Disconnected by services) |
| 09:48:00 | * | gour_ joined #nimrod |
| 09:55:23 | * | apriori| joined #nimrod |
| 10:17:24 | Araq | ugh libffi uses autoconf ... :-/ |
| 10:19:51 | Araq | "It's also possible to build libffi on Windows platforms with |
| 10:19:53 | Araq | Microsoft's Visual C++ compiler. In this case, use the msvcc.sh |
| 10:19:55 | Araq | wrapper script ... " |
| 10:20:09 | Araq | yeah, right, let me run a UNIX shell script on windows ... |
| 10:47:07 | Zor | I have managed to build libffi on windows under cygwin, mingw32, and mingw64 |
| 10:47:12 | Zor | haven't tried with msvc |
| 10:49:23 | Araq | makes me want to avoid it and write my own libffi :P |
| 10:49:53 | Zor | I thought of that but ended up abandoning the idea |
| 10:50:07 | Zor | there is a *lot* of *very* error prone code in libffi for all sorts of architectures |
| 10:50:35 | Araq | yeah but there is an easier way to do all this |
| 10:50:56 | Zor | ? |
| 10:51:33 | Araq | ((properFunctionType) function)(word1, word2, word3, word3) |
| 10:51:50 | Araq | it's quite inflexible |
| 10:52:26 | Zor | libffi is meant for cases where you do not know the amount of args or their values |
| 10:52:31 | Zor | e.g. interpreters |
| 10:52:32 | Araq | but then how many of the potentially possible function signatures do you really end up using? |
| 10:53:02 | Zor | if all you're doing is some statically typed function calls on arbitrary memory, you don't need libffi at all |
| 10:53:12 | Araq | I'm well aware of the use cases of libffi, I'm writing an interpreter |
| 10:53:39 | Zor | then I don't understand < Araq> yeah but there is an easier way to do all this |
| 10:54:34 | Araq | you can change the base problem slightly: only care for the ~30 signatures that are really used in practice |
| 10:55:00 | Araq | and hard code them in a case statemetn and cast the function pointer |
| 10:55:01 | * | Zor shrugs |
| 10:55:07 | Zor | I would not want to put arbitrary limitations on it |
| 10:55:29 | Araq | *shrug* it's worth a try |
| 10:55:34 | Zor | also, that strategy does not work portably at all - on some architectures, pointers are passed in different regs than integrals, and floats may be in other regs still, and so on |
| 10:55:56 | Zor | libffi takes care of all the ABI mess for you, which is why it's appealing |
| 10:56:04 | Araq | it does work perfectly fine with floats |
| 10:56:30 | Zor | ? |
| 10:56:57 | Araq | you can have a signature like (pointer, float, float, pointer) |
| 10:57:17 | Araq | if that signature is actually used somewhere which I doubt btw |
| 10:58:45 | Araq | if your problem is "arbitrary types" and an arbitrary length of the param list then yes, you need libffi |
| 10:59:03 | Araq | but most C code doesn't pass structs per value |
| 10:59:42 | Araq | nor do many functions exist with 500 parameters |
| 11:00:29 | Araq | so it looks quite managable to only care for the signatures that say, posix, windows and opengl really use |
| 11:05:23 | Araq | btw on which non-archaic architecture are integrals separated from integrals for argument passing? |
| 11:05:45 | Araq | er "pointers separated from integrals" |
| 11:09:40 | Zor | I can't remember, I'd have to dig through each libffi architecture to find out |
| 11:12:54 | Araq | plus my solution looks like being much faster :P |
| 11:14:48 | * | apriori| quit (Quit: Konversation terminated!) |
| 11:15:24 | Zor | it probably is, but personally, I'd prefer a more generic solution |
| 11:15:42 | Zor | what are you writing an interp for? |
| 11:16:01 | Araq | we want the FFI to be available at compile time |
| 11:16:32 | Araq | improving the evaluator to be useful as a real interpreter |
| 11:16:35 | Zor | that's even more reason to use a generic solution imho |
| 11:16:42 | Zor | (if it's part of a compiler) |
| 11:17:08 | Zor | trust me, sooner or later, somebody *will* complain about an obscure use case you never thought would happen |
| 11:17:20 | Araq | why? we can always say: "error: function signature not supported at compile time" |
| 11:17:33 | Zor | programmers don't like arbitrary limitations :) |
| 11:18:06 | Araq | I think you can't pass more than 32K to a x86 function on the stack |
| 11:18:15 | Araq | nobody complains :P |
| 11:18:53 | Araq | arbitrary limitations are everywhere |
| 11:20:28 | Araq | and even libffi doesn't support unions nor bit fields; it's just the question where you want to draw the line |
| 11:22:10 | Zor | it does "support" them |
| 11:22:26 | Zor | in the sense that you just build up a libffi struct type large enough to hold them |
| 11:42:08 | Araq | fair enough, but getting the alignment right of a union nested in a struct is quite callenging |
| 11:49:46 | Araq | m68k distinguishes pointers from integerals iirc |
| 11:49:59 | Araq | which is a dead arch |
| 11:50:15 | Araq | (or at least an arch I don't care about) |
| 11:56:28 | * | Trixar_za is now known as Trix[a]r_za |
| 12:12:00 | Araq | but meh, libffi is it |
| 12:15:33 | Araq | why is it that most the C code I read doesn't perform any useful work but instead is concerned to get the bit sized integers right and checking for malloc's return value? |
| 12:24:09 | Zor | The One True Language (tm) |
| 12:26:28 | Araq | it should also check there is enough space on the stack left to call a function :P |
| 12:27:36 | Araq | what do you mean, "you can't do that in C?" why check if malloc succeeded then? |
| 12:47:54 | Araq | Zor: any idea what LIBFFI_HIDE_BASIC_TYPES is supposed to do? |
| 12:48:57 | Zor | no, and I've never had to care about it either (when using libffi from D) |
| 13:18:11 | * | q66 joined #nimrod |
| 16:04:33 | dom96 | hello |
| 16:07:38 | dom96 | Not a bad answer from the github guy: https://github.com/github/linguist/pull/253#issuecomment-11480151 |
| 16:37:05 | * | zahary1 joined #nimrod |
| 16:38:53 | * | zahary quit (Ping timeout: 255 seconds) |
| 17:17:07 | Araq | dom96: are you serious? "In the meantime though, there are some concerns that making the change proposed here would result in some performance regressions on the site." |
| 17:17:32 | Araq | what does the patch do? |
| 17:17:32 | dom96 | Better than no response at all. |
| 17:17:40 | Araq | that's true |
| 17:17:59 | dom96 | And at least it shows that they care somewhat. |
| 17:18:06 | Araq | "oohh we use Rails and are concerned with performance regressions" |
| 17:18:19 | Araq | Rials is huge performance regression itself |
| 17:18:31 | dom96 | lol |
| 17:18:53 | dom96 | I don't really get how this can result in performance regressions. |
| 17:19:09 | dom96 | I mean, is it because they will run pygments on potential binary files? |
| 17:19:46 | dom96 | in that case they need more sensible detection than just using extension names. |
| 17:19:53 | * | gradha joined #nimrod |
| 17:19:54 | dom96 | As I can easily change a .exe file into a .c file. |
| 17:20:30 | gradha | dom96: I want you to teach me about this alchemy you sell |
| 17:20:53 | dom96 | what? |
| 17:21:11 | gradha | just logged in and got "As I can easily change a .exe file into a .c file." |
| 17:21:18 | gradha | yeah, ok, will read the logs now |
| 17:21:22 | dom96 | I see. |
| 17:21:36 | dom96 | yeah, read the logs |
| 17:24:04 | gradha | I believe one of the goals of HURD was to remove arbitrary posix limitations like filename/directory/path length |
| 17:24:16 | gradha | I guess they are still dealing with the arbitrary limitation of releasing something |
| 17:24:52 | * | XAMPP joined #nimrod |
| 17:24:52 | * | XAMPP quit (Changing host) |
| 17:24:52 | * | XAMPP joined #nimrod |
| 17:25:54 | Araq | I will answer cobyism |
| 17:26:14 | dom96 | Araq: Be nice please |
| 17:26:38 | dom96 | And mention him by name btw |
| 17:36:11 | gradha | today I learned that a 3 year old software I wrote was entering an infinite loop if people fed it CMYK jpg images rather than RGB |
| 17:36:27 | gradha | morale: maintenance sucks |
| 17:36:48 | gradha | also, didn't even know you could have CMYK jpg |
| 17:45:44 | Araq | gradha: but on the positive side, that means somebody uses your software :P |
| 17:47:12 | gradha | not so sure about that, they have two months worth of fixes and improvements and they don't want to release them, instead they are "fixing" their server to send RGB images |
| 17:47:36 | gradha | so they prefer using an old version? weird |
| 17:49:38 | gradha | releasing is a matter of compiling and uploading the binary to the app store, so I don't want to even imagine the politics that they have to deal with each release if they prefer having known bugs |
| 17:50:34 | gradha | See the table tracking released versions at http://gradha.github.com/OpenIrekia-iOS/ |
| 17:50:56 | gradha | makes me very sad |
| 17:53:47 | gradha | dom96: your comments yesterday got me thinking about ios programming with nimrod |
| 17:54:07 | gradha | you can definitely replace all objc code with nimrod (generating objc code instead) |
| 17:54:29 | gradha | however, you lose some useful stuff, like the GUI integration and core data/storyboard generation |
| 17:54:49 | gradha | so even if possible, might not always be the best option |
| 18:02:06 | dom96 | wouldn't it be possible to get fairly similar GUI integration etc. with a module which generates proper Objective C code? |
| 18:03:03 | gradha | the idea of the integration is that you use xcode's gui which modifies your source |
| 18:03:45 | gradha | also, for some GUI stuff xcode scans your source files and builds up from that when you "connect" interface operations |
| 18:04:08 | gradha | say, you have an objc property, then it appears inside xcode gui builder and you can "link" it to some action |
| 18:05:29 | gradha | maybe I should look at how the monotouch guys do it and "steal" some ideas |
| 18:35:03 | gradha | I updated https://github.com/Araq/Nimrod/pull/288, do you get any github notifications if I force a push to update the code? |
| 18:35:52 | Araq | nope |
| 18:37:38 | dom96 | omg, I wish my mum was a geek. |
| 18:37:50 | dom96 | or knew to buy me stuff from ThinkGeek :P |
| 18:38:35 | gradha | Try sending here an email in the form "Buy this for your geek son this christmas!" |
| 18:38:42 | gradha | Most of them don't check the from address anyway |
| 18:39:23 | dom96 | hah, my mum doesn't check her email. |
| 18:39:30 | dom96 | It would be more effective to use Facebook... |
| 18:39:33 | dom96 | but then... |
| 18:39:42 | dom96 | it's hard to fake who you are. |
| 18:39:48 | gradha | you can try printing an ad and putting it in the mailbox |
| 18:40:08 | dom96 | lol |
| 18:40:16 | dom96 | might work :P |
| 18:40:38 | gradha | it has to, that's how Santa gets all the amazon whishlists |
| 18:48:19 | * | apriori_ joined #nimrod |
| 18:49:49 | * | FreeArtMan joined #nimrod |
| 19:32:19 | * | gradha quit (Quit: gradha) |
| 19:32:39 | Araq | if it's called "libffi" is the .so then liblibffi.so? |
| 19:33:49 | dom96 | lol |
| 19:33:59 | dom96 | Something tells me it's not. |
| 19:34:04 | Araq | it's libffi.so apparently, yeah |
| 19:34:19 | Araq | so what's it on windows? libffi.dll ? |
| 19:34:29 | Araq | we'll find out ... |
| 20:32:50 | Zor | yes, libffi.a/.lib/.dll |
| 20:35:10 | Araq | how do I dlopen libc again? |
| 20:38:20 | Araq | "libBrokenLocale" ? wtf? |
| 20:40:20 | Araq | Zor: anything more portable than "libc.so.6"? |
| 20:48:00 | Zor | probably not... |
| 20:48:20 | Araq | I remember you could do dlopen("") to get the same |
| 20:48:30 | Araq | but maybe I'm wrong |
| 20:53:05 | * | apriori_ quit (Quit: Konversation terminated!) |
| 20:55:20 | * | gour_ quit (Quit: WeeChat 0.3.8) |
| 21:27:20 | * | FreeArtMan quit (Ping timeout: 255 seconds) |
| 23:58:35 | * | NimBot_ quit (Remote host closed the connection) |
| 23:58:51 | * | NimBot_ joined #nimrod |