| 00:00:28 | Varriount | The compiler is reading the 'gcc.options.always' line, even when using the g++ c compiler. |
| 00:00:39 | Araq | ah |
| 00:00:55 | Varriount | Adding -fpermissive to the 'gcc.options.always' line fixes things. |
| 00:01:45 | Varriount | Araq: I don't think that's a suitable fix - is it? |
| 00:01:59 | Araq | nope |
| 00:02:07 | Varriount | You can't set a cpp specific options. |
| 00:02:17 | Varriount | *option |
| 00:02:28 | Araq | the compiler should use gpp options for 'cpp' |
| 00:02:47 | Varriount | So.. special case it? Or create a separate compiler entry? |
| 00:04:09 | * | darkf joined #nimrod |
| 00:07:34 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:08:49 | Araq | Varriount: the other C/C++ compilers have the same problem |
| 00:09:08 | Araq | it's not GCC specific, there is clang and clang++ |
| 00:09:22 | Varriount | Araq: So something needs to be done to alter the entire config reading system. |
| 00:09:31 | Araq | maybe append 'pp' to the config C compiler name |
| 00:09:53 | Araq | that produces, gccpp, clangpp etc. config entries. good enough. |
| 00:10:18 | Araq | (well append that when in c++ mode) |
| 00:10:27 | Varriount | Yeah. Not the best case, but workable |
| 00:11:03 | Varriount | Ideally we could just use 'g++', but I"m guessing the config file parser would have problems with that. |
| 00:12:53 | Varriount | flaviu: Do any *nix systems have something on par with Window's Group Policy? |
| 00:14:26 | flaviu | Varriount: Thats a broad question, but the OS doesn't care about stuff like that. Perhaps asking "Is there a way to have group policy feature X with linux programs" |
| 00:15:10 | flaviu | Also, all I know about GP is that it can disable administrative windows snap-ins, which is easy in linux: don't add the user to sudoers |
| 00:20:17 | * | Jehan_ joined #nimrod |
| 00:25:10 | Araq | interesting discussion: http://tmrepository.com/fudtracker/rob-pike-admits-it-modern-unix-is-a-mess/ |
| 00:25:16 | Araq | good night |
| 00:28:00 | Varriount | flaviu: Ok. On linux, can you prevent the user from running an arbitrary program, even if it doesn't have a definite existance or location? |
| 00:29:10 | Varriount | Window's allow administrators to say that certain executables (say, teamviewer) aren't allowed to be run. Usually this is done either by filename inspection, or by inspection of the certificates and metadata stored in the executables. |
| 00:29:19 | flaviu | lol, what a joke |
| 00:29:27 | flaviu | so if I recompile it, what happens? |
| 00:29:38 | Varriount | *shrug* |
| 00:30:00 | Jehan_ | Varriount: Not sure what the context is, but this strikes me as a mostly pointless feature? |
| 00:30:24 | flaviu | But ok, you can do that on linux too. Write a program to use inotify and do whatever filtering you want. |
| 00:30:39 | Varriount | Jehan_: Well, my highschool used it to block RDP clients, (like teamviewer) from being run. |
| 00:30:42 | flaviu | It won't actually work, but it'll check off the right boxes for your superior. |
| 00:31:31 | Jehan_ | Varriount: If your users are smart enough to circumvent the system in the first place, there is no difference between renaming and modifying the executable, for all practical purposes. |
| 00:32:06 | Jehan_ | If either can be done, one student will figure it out, and the rest will copy it. |
| 00:32:22 | flaviu | Jehan_: The thing is, the guy who's telling you to do this doesn't realize that. You just have to make it hard enough to do that he's happy |
| 00:34:51 | Jehan_ | Is is really hard to keep an enterprising person on a Turing-complete machine from doing what they want to do. |
| 00:35:28 | flaviu | Just wait until some kid discovers the wonders of X forwarding |
| 00:36:34 | Varriount | I'm looking through the group policy console right now.. |
| 00:37:10 | Jehan_ | Just looking at the web, there's an RDP extension for Chrome, for example. |
| 00:37:46 | Varriount | Huh, you can stop someone from using the profiling and debugging API's that Windows provides. |
| 00:38:02 | flaviu | Why would you want to do that? |
| 00:38:34 | Jehan_ | flaviu: Because there are managers that depend on the BDSM style of employee management? |
| 00:38:40 | Varriount | You don't neccesarily want someone trying to tinker with running programs. |
| 00:39:16 | flaviu | Jehan_: Yes, especially in this whole "public school" thing where students have zero leverage ;) |
| 00:39:27 | Jehan_ | If it's a shared system, they shouldn't be able to mess with other people's processes, anyway. If it's their own, it's their own to mess up. |
| 00:39:50 | * | enurlyx left #nimrod (#nimrod) |
| 00:40:02 | Varriount | "Devices: Allow to format and eject removable media" |
| 00:40:25 | flaviu | Again, why should the admins give a damn about that? |
| 00:40:40 | flaviu | But that applies by default on linux, no configuration necessary. |
| 00:42:08 | Varriount | Here's a wierd one: "Remove computer from docking station" |
| 00:42:14 | Jehan_ | Heh. |
| 00:42:32 | Varriount | I guess if you do so, and you aren't allowed to, you get logged off? |
| 00:42:33 | Jehan_ | The thing is, security policies are known not to be composable. |
| 00:42:38 | flaviu | Varriount: You can disable task manager too! |
| 00:42:53 | flaviu | Varriount: But don't forget to lock down the registry or its all in vain :P |
| 00:42:54 | Jehan_ | So, with any combination of such fine-grained settings, you're probably enabling some things that you didn't think of. |
| 00:45:15 | Varriount | Hm, how do you enforce disk quotas on linux? |
| 00:45:52 | flaviu | Varriount: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/System_Administration_Guide/ch-disk-quotas.html |
| 00:47:59 | Jehan_ | Looking through the logs: If you want to use -fpermissive to allow implicit conversions from const T* to T*, that won't work with clang. |
| 00:48:44 | flaviu | why bother with const in the first place? |
| 00:50:12 | Jehan_ | flaviu: Because some header files do declare stuff as const, but Nim has no means to represent importc stuff as const. |
| 00:52:21 | Varriount | Jehan_: Is there an easy workaround? |
| 00:53:22 | * | Trustable quit (Quit: Leaving) |
| 00:53:42 | Jehan_ | Varriount: In C++11, cast to (decltype(target)) |
| 00:54:31 | Jehan_ | In gcc/clang for earlier versions, typeof() and __typeof() can also be used. |
| 00:54:51 | Varriount | Jehan_: Can that be used verbatim? |
| 00:55:05 | Jehan_ | I think we had already been discussing to allow for an extended importc syntax. |
| 00:55:18 | Varriount | Or does 'target' mean the target variable/type? |
| 00:55:29 | Jehan_ | I.e. where you do {.importc: "(char *)(foo($1))".} |
| 00:55:41 | Jehan_ | Varriount: target is whatever the value gets assigned to. |
| 00:55:54 | Jehan_ | decltype/typeof figures out the type of an expression. |
| 00:56:10 | Varriount | What about function arguments though? |
| 00:56:52 | Jehan_ | Doesn't have to be the literal target, can also be "what you think the type should be". |
| 00:57:00 | * | ehaliewicz quit (Ping timeout: 250 seconds) |
| 00:57:04 | Jehan_ | Besides, function arguments are generally not the problem. |
| 00:57:20 | Jehan_ | Since you can always add const/volatile implicitly, you just can't strip it. |
| 00:57:51 | Jehan_ | Nim values never should have const/volatile, so they can always be passed to functions expection const/volatile arguments. |
| 00:58:58 | Jehan_ | If I had to hack a quick fix together, I'd simply do a cast of importc functions to their expected return type. |
| 00:59:22 | Jehan_ | E.g., gai_strerror() is declared as a cstring in Nim, so I'd cast it to a (char *). |
| 01:00:37 | Jehan_ | The downside is that this blows up code complexity for the C++ target. |
| 01:00:51 | Jehan_ | If you have lots of external function calls. |
| 01:05:52 | Jehan_ | Luckily, it's a C++-only problem. |
| 01:06:05 | Jehan_ | C and Objective C treat that as a warning only. |
| 01:06:36 | Jehan_ | Which is not what you want if you actually program in either language, but makes them much nicer as target languages for compilers. |
| 01:12:48 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 01:19:25 | BitPuffin | Jehan_: -Werror |
| 01:20:00 | Jehan_ | BitPuffin: -Werror is the other extreme -- it's too aggressive. |
| 01:20:15 | Jehan_ | It makes things errors that are completely harmless. |
| 01:21:09 | Jehan_ | Not to mention warnings that you can't avoid, because they come from external libraries. |
| 01:21:38 | Jehan_ | I've always wanted to figure out a set of warnings that combined with -Werror give you decent error reporting, but have been too lazy to do that. :) |
| 01:22:26 | Jehan_ | Plus, it would result in really, really long command lines. :) |
| 01:27:25 | * | Fr4n joined #nimrod |
| 01:27:29 | * | Francisco quit (Ping timeout: 255 seconds) |
| 01:35:59 | * | xenagi quit (Quit: Leaving) |
| 01:45:08 | superfunc | Jehan_: why not -werror and suppress the superfluous warnings? |
| 01:45:22 | Jehan_ | superfunc: What do you mean? |
| 01:46:50 | superfunc | I though werror just turned warnings to errors |
| 01:51:38 | Jehan_ | -Werror does. |
| 01:51:52 | Jehan_ | The problem is that there are a ton of harmless warnings that then also get turned into errors. |
| 02:01:41 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 02:06:47 | Varriount | Wow. the external compiler configuration code is actually quite nice looking |
| 02:07:39 | Jehan_ | Varriount: Yeah, it's a nice example of using Nim for internal DSLs. |
| 02:10:02 | Jehan_ | My main issue with the compiler is stuff like TLoc with all its one-letter names for important fields. |
| 02:11:28 | Jehan_ | Still haven't figured out what TLoc.a is for, since it's not documented and grepping for a (even grep -w a) is hopeless. |
| 02:15:18 | superfunc | Jehan_: I meant that hopefully we could suppress the harmless warnings so we could leave -Werror on |
| 02:15:37 | Jehan_ | superfunc: Yeah, that's what I was talking about. |
| 02:18:44 | Varriount | Jehan_: That |
| 02:19:01 | Varriount | That's why any change to the compiler code should add documentation as well as fixes. |
| 02:20:12 | Jehan_ | Varriount: Heh. Guilty as charged. :) |
| 02:21:52 | * | superfunc__ quit (Ping timeout: 246 seconds) |
| 02:22:22 | Varriount | Yes, some might consider documentation is certain areas of the compiler to be... redundant, however in a program as complicated as the Nim compiler, I'd rather have an excess of explanation than too little. |
| 02:25:59 | Jehan_ | Varriount: Agreed. |
| 02:26:11 | Jehan_ | Mind you, it's not any better in, say, clang. |
| 02:26:42 | Jehan_ | I keep wanting to use some of the parts of clang for my day job, but keep getting frustrated by its internal complexity. |
| 02:26:52 | Jehan_ | Not that gcc is any better, mind you. Probably worse. |
| 02:28:36 | Varriount | Jehan_: Really? I was under the impression - from what I've heard about clangs 'shinyness' - that clang was documented |
| 02:31:02 | Jehan_ | Varriount: Parts are well documented, other parts are … lacking. |
| 02:33:42 | Jehan_ | What I'm interested in is using clang for source-to-source translation. |
| 02:34:07 | Jehan_ | Which is not trivial to use, and the features I need are hard to figure out. |
| 02:34:10 | Varriount | Say.. C++ to Nim transformation? :3 |
| 02:34:21 | Jehan_ | No, C++-to-C++. |
| 02:34:35 | Jehan_ | In the end, I wrote this from scratch in Nim. |
| 02:34:46 | Jehan_ | It was easier than figuring out clang. :) |
| 02:34:50 | Varriount | Jehan_: What needed to be translated? |
| 02:34:53 | Jehan_ | Or at least, those parts of clang. |
| 02:35:06 | Jehan_ | Varriount: Inter alia, turning global and static variables into thread-local variables. |
| 02:35:38 | Varriount | Jehan_: Interesting. |
| 02:36:24 | Jehan_ | And Nim is a joy to work with for this kind of application. |
| 03:25:09 | * | Jehan_ quit (Quit: Leaving) |
| 03:25:23 | * | flaviu quit (Ping timeout: 255 seconds) |
| 03:38:46 | * | Boscop__ joined #nimrod |
| 03:39:17 | * | Boscop__ is now known as Boscop |
| 03:52:46 | * | will quit (Ping timeout: 255 seconds) |
| 04:09:47 | * | ehaliewicz joined #nimrod |
| 05:25:17 | * | ehaliewicz quit (Remote host closed the connection) |
| 06:13:31 | Varriount | I just wrote up a 43 line explanation (max 79 char columns) of how functions in batch work, including arguments, scopes, and return values. |
| 06:44:58 | Varriount | For anyone interested: https://gist.github.com/Varriount/3db50b6816e7a58d37ae |
| 07:22:55 | * | noam_ quit (Ping timeout: 244 seconds) |
| 07:48:03 | Araq | er ... TLoc.a wasn't used for anything interesting and is gone in bigbreak |
| 07:52:45 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 07:55:20 | * | vendethiel joined #nimrod |
| 07:58:14 | * | irrequietus joined #nimrod |
| 08:02:31 | * | irrequietus quit (Client Quit) |
| 08:03:07 | * | irrequietus joined #nimrod |
| 08:08:03 | * | BlaXpirit joined #nimrod |
| 08:16:29 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 08:21:51 | * | vendethiel joined #nimrod |
| 08:38:40 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 09:21:08 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 09:30:29 | * | gokr joined #nimrod |
| 09:37:16 | * | Matthias247 joined #nimrod |
| 09:42:02 | * | Francisco joined #nimrod |
| 09:44:19 | * | Fr4n quit (Ping timeout: 265 seconds) |
| 09:57:49 | * | Fran__ joined #nimrod |
| 09:59:32 | * | Francisco quit (Ping timeout: 250 seconds) |
| 10:24:47 | * | irrequietus quit (Ping timeout: 244 seconds) |
| 10:49:48 | * | untitaker quit (Ping timeout: 250 seconds) |
| 11:02:34 | * | untitaker joined #nimrod |
| 11:10:55 | * | xcombelle joined #nimrod |
| 11:20:10 | * | xcombelle quit (Ping timeout: 256 seconds) |
| 11:34:33 | * | BitPuffin joined #nimrod |
| 11:37:00 | * | BitPuffin left #nimrod (#nimrod) |
| 11:46:39 | * | xcombelle joined #nimrod |
| 11:52:16 | * | rpag quit (Quit: Leaving) |
| 11:56:45 | * | untitaker quit (Ping timeout: 244 seconds) |
| 11:57:44 | * | untitaker joined #nimrod |
| 12:19:17 | * | gokr_ joined #nimrod |
| 12:19:19 | * | gokr quit (Read error: Connection reset by peer) |
| 12:22:09 | * | flaviu joined #nimrod |
| 12:28:44 | * | gokr1 quit (Ping timeout: 256 seconds) |
| 12:35:04 | * | gokr joined #nimrod |
| 12:36:21 | * | will joined #nimrod |
| 12:38:05 | * | gokr_ quit (Ping timeout: 244 seconds) |
| 12:44:22 | flaviu | Varriount: Batch is easy mode ;) Try an nonstructured programming language - you have to develop your own calling conventions. |
| 12:44:59 | Araq | I still think we should compile a subset of Nim to batch and posix shell |
| 12:45:16 | Araq | ... only 1 script to maintain |
| 12:49:53 | flaviu | Araq: You could do it like emscriptem! Open a temp file and use it as main memory. |
| 12:51:12 | Araq | really? but that supports random access. A "file" doesn't. ;-) |
| 12:53:13 | * | dom96_ joined #nimrod |
| 12:53:28 | dom96_ | gokr: thanks for mentioning me in your article :) |
| 12:53:48 | flaviu | dd if=tmpfile count=1 bs=objsize obs=16 seek=pos/16 |
| 12:54:04 | flaviu | That's how you can read from main memory |
| 12:54:34 | * | EastByte_ joined #nimrod |
| 12:54:35 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 12:56:22 | * | clone1018__ joined #nimrod |
| 12:56:42 | * | clone1018_ quit (Ping timeout: 260 seconds) |
| 12:56:42 | * | EastByte quit (Ping timeout: 260 seconds) |
| 12:56:43 | * | dom96 quit (Ping timeout: 260 seconds) |
| 12:56:44 | * | CARAM quit (Ping timeout: 260 seconds) |
| 12:57:09 | * | CARAM_ joined #nimrod |
| 12:57:14 | flaviu | Although it would be more portable to just use variables with binary contents and a helper program to extract values. |
| 12:58:28 | flaviu | You could also do stuff like mm36423_fieldname, I suppose that would be easiest. |
| 12:58:45 | * | Jehan_ joined #nimrod |
| 12:59:08 | * | xcombelle quit (Ping timeout: 255 seconds) |
| 13:00:13 | Jehan_ | Araq, Varriount: koch csource is currently broken, because the variable "mingw" is not defined. |
| 13:00:28 | * | dom96 joined #nimrod |
| 13:00:49 | Araq | Jehan_: already fixed it |
| 13:00:55 | Jehan_ | Ah, thanks. :) |
| 13:00:59 | Araq | maybe I didn't push it |
| 13:04:23 | Jehan_ | Looks like it. |
| 13:04:33 | Jehan_ | But as long as it's in the pipeline, that's fine. :) |
| 13:12:01 | * | gokr1 joined #nimrod |
| 13:12:06 | gokr1 | hey |
| 13:13:44 | Jehan_ | Araq: Speaking of unpushed stuff, the most recent version produces: Error: invalid pragma: benign |
| 13:14:10 | Jehan_ | It looks like there's a lot of code transitioned to benign instead of gcsafe, but the pragma isn't actually defined anywhere. |
| 13:14:32 | * | gokr1 sitting in some newly opened playland with free wifi... girls are gone in an instant |
| 13:15:09 | Jehan_ | Or rather, not anywhere where it can be found. |
| 13:15:23 | * | BitPuffin joined #nimrod |
| 13:16:25 | * | darkf quit (Quit: Leaving) |
| 13:17:00 | dom96_ | gokr1: hey, thanks for mentioning me in your article :) |
| 13:17:11 | gokr1 | :) |
| 13:17:36 | gokr1 | You seem to have been cranking out quite a lot of Nim stuff. |
| 13:17:50 | gokr1 | Are you responsible for the networking layer? |
| 13:18:10 | gokr1 | As in "wrote most of it"? |
| 13:18:11 | Araq | Jehan_: I know, already fixed it |
| 13:18:16 | dom96_ | gokr1: yeah. Not right now though as I am busy with Uni. |
| 13:18:50 | Jehan_ | Okies, going to roll back a few revisions until the branch has stabilized again. |
| 13:19:05 | Araq | it's only the very latest push I think |
| 13:19:38 | gokr1 | Do you know if Nim is being used in any heavy networking app? Just curious. |
| 13:19:42 | Jehan_ | Yeah, but the mingw variable also. |
| 13:20:57 | gokr1 | Since I am learning Nim - its pretty easy to contribute by writing these articles "as I go". |
| 13:22:43 | flaviu | gokr: The forums are in nim, as is the build system |
| 13:23:00 | flaviu | http://build.nimrod-lang.org/ |
| 13:23:25 | * | relumelu joined #nimrod |
| 13:23:38 | gokr1 | Personally the only "weakness" I can see right now would be the dev env. Our system is in Smalltalk today and we use the Smalltalk toolset quite a lot so... that's where I still wonder slightly how things will turn out. |
| 13:24:01 | gokr1 | But nothing prevents us from improving on that :) |
| 13:24:54 | Jehan_ | gokr1: Tooling is generally the biggest challenge for a new language. |
| 13:25:55 | Jehan_ | I'd actually say the biggest challenge for Nim at the moment is the debugging situation, not the IDE stuff. |
| 13:26:13 | flaviu | Jehan_: Huh? C debugger works great. |
| 13:26:27 | gokr1 | I did try out debuggers - and ... many of them work quite fine - but the "data explorer" side of it is the bit to "fix2. |
| 13:26:30 | gokr1 | "fix". |
| 13:26:31 | Jehan_ | flaviu: I'd say it works okay. Not great. |
| 13:26:56 | gokr1 | I was wondering (as perhaps you saw) if we couldn't set up some GDB pretty printer that calls a Nim lib to do the work. |
| 13:27:21 | Jehan_ | gokr1: I've thought the same thing, using Python scripting. |
| 13:27:44 | gokr1 | Yeah, the GDB pretty printer is Python - but we can just have Python call a Nim lib and do the work there. |
| 13:27:54 | gokr1 | Or perhaps... hmm. Perhaps not that easy. |
| 13:28:39 | gokr1 | But stepping etc works quite nicely. KDevelop (on Linux) seems to work really well for example. |
| 13:28:54 | Jehan_ | flaviu: Try to display a seq[seq[int]], for example. :) |
| 13:30:09 | Jehan_ | Also, figuring out which C function corresponds to which generic instantiation can be a problem. |
| 13:32:46 | * | irrequietus joined #nimrod |
| 13:34:26 | dom96_ | yeah, debugging is definitely something we need to improve. |
| 13:34:28 | * | gokr2 joined #nimrod |
| 13:38:26 | Jehan_ | A workaround for displaying complex data is to define a function with {.exportc.} and then calling it from gdb. |
| 13:38:29 | Jehan_ | E.g.: |
| 13:38:40 | Jehan_ | proc print_int_seq(a: seq[int]) {.exportc.} = |
| 13:38:41 | Jehan_ | echo a |
| 13:39:52 | * | gokr1 quit (*.net *.split) |
| 13:39:52 | * | woodgiraffe quit (*.net *.split) |
| 13:39:52 | * | milosn_ quit (*.net *.split) |
| 13:41:01 | * | kuzy000 joined #nimrod |
| 13:41:49 | * | milosn joined #nimrod |
| 13:42:01 | gokr2 | So apart from plugins for various editors etc, Aporia is the "only" IDE effort in Nim, or? |
| 13:42:41 | dom96_ | yes |
| 13:43:27 | gokr2 | When we looked at Lua we played with Zerobrane Studio - a wx based IDE written all in Lua. |
| 13:44:13 | gokr2 | But gtk is just as portable I guess - although not as "native looking". |
| 13:44:35 | * | will quit (Ping timeout: 255 seconds) |
| 13:44:50 | gokr2 | dom96_: Did you think any about how debugging would be best "solved" in Aporia? Still interfacing with gdb or? |
| 13:44:56 | Araq | in fact, we use our own file dialogs, so we get the native ones on windows |
| 13:45:32 | Araq | apart from the file dialogs, gtk on windows is quite "native looking" |
| 13:45:36 | Jehan_ | gokr2: Other alternatives to piggyback on would be IDEA or MonoDevelop. Or, umm, Eclipse, I guess. |
| 13:45:44 | gokr2 | Araq: It uses the WIMP thing, right? |
| 13:46:07 | * | kuzy000 quit (Remote host closed the connection) |
| 13:46:17 | gokr2 | Jehan_: There are tons, but... perhaps it would be better if we simply improved on Aporia. |
| 13:46:27 | Jehan_ | gokr2: I know. |
| 13:46:39 | Jehan_ | I'm painfully aware of how much work that would be. |
| 13:47:08 | gokr2 | I am thinking that it would be neat if we had our own IDE written *in Nim* but perhaps its the Smalltalker in me talking. |
| 13:47:42 | Araq | best alternative to Aporia would be to build upon Lazarus, I think |
| 13:48:12 | Jehan_ | gokr2: The main problem I have with Aporia is that it simply is too much of a pain to get to work on a Mac. If that's possible at all right now. |
| 13:48:52 | gokr2 | Araq: Aha, I am definitely not well versed in the Pascal arena :) |
| 13:49:00 | wan | I was thinking about writing an editor in Nim, one that would have direct access to the AST to have some nice navigation |
| 13:49:29 | gokr2 | Araq: Can pas2nim translate Lazarus to Nim? ;) |
| 13:50:20 | Araq | gokr2: no way. modern pascal is C-like enough to make everything as painful |
| 13:50:39 | gokr2 | Oh, they have their own UI layer. |
| 13:51:45 | gokr2 | Anyone did a wx wrapper? |
| 13:53:54 | Araq | I did once |
| 13:54:12 | Araq | well |
| 13:54:21 | Araq | I never completed it |
| 13:55:17 | Araq | the wx api is not nice to use/wrap |
| 13:55:21 | dom96_ | Jehan_: What's the problem with getting it to work on a Mac? Is GTK simply not good on Macs? |
| 13:55:36 | Jehan_ | dom96: Umm, the problem is that it crashes during startup? |
| 13:56:41 | dom96_ | Why not report it on Github then? |
| 13:56:48 | dom96_ | Maybe I can fix it. |
| 13:56:52 | * | Araq once prototyped the same application with both Delphi and wxPython. |
| 13:57:06 | dom96_ | Although I guess it might be a compiler problem? |
| 13:57:08 | Jehan_ | dom96: Do you have a Mac to reproduce the error and figure out why it happens? |
| 13:58:14 | Jehan_ | The other thing is that personally I don't really care much for IDEs, so it's not really a priority for me. |
| 13:59:17 | Jehan_ | The general problem is that any IDE forces me to use its editor. |
| 13:59:21 | dom96_ | Jehan_: Unfortunately I don't. |
| 13:59:48 | Jehan_ | dom96: Yeah, that's why I didn't bother. Macs just aren't all that popular in the Nim community, outside of gradha and myself. :) |
| 14:00:08 | * | woodgiraffe joined #nimrod |
| 14:00:15 | dom96_ | Although my girlfriend has one, just asked her and it seems she will let me use it :) |
| 14:01:20 | gokr2 | For us OSX and Windows are our primary client platforms. |
| 14:01:27 | gokr2 | And all Linux server side. |
| 14:01:33 | Jehan_ | Okay, I'll see if I can dig further into it and find out more. |
| 14:01:57 | Jehan_ | FWiW, it crashes in listStoreNew, it appears, with a null pointer exception. |
| 14:02:13 | gokr2 | Thing is - a language like Nim could offer magnificent cross referencing in an IDE. |
| 14:02:37 | gokr2 | and these things tend to become more interested with a larger codebase. |
| 14:02:41 | gokr2 | interesting. |
| 14:03:26 | gokr2 | dom96_: I have a mac, but haven't tried Aporia there yet. |
| 14:04:21 | dom96_ | I think even if we get it working it will look absolutely terrible on a Mac. |
| 14:04:24 | Jehan_ | dom96: I'm using gtk+-2.24.24. |
| 14:04:49 | Jehan_ | dom96: Well, MonoDevelop/Xamarin Studio also uses gtk underneath, and it's pretty much okay. |
| 14:04:49 | gokr2 | The Zerobrane Studio is MIT btw. Quite small codebase. |
| 14:05:09 | dom96_ | Jehan_: Maybe it's a case of getting the correct themes. |
| 14:05:38 | Jehan_ | dom96: I believe the Mac gtk port uses native widgets. |
| 14:05:39 | dom96_ | Maybe MonoDevelop uses some Mac OS APIs to make it nicer. |
| 14:05:59 | Jehan_ | I know there's an option to build Gtk for the Mac without X11. |
| 14:07:28 | Araq | yup and that's what mono uses I think |
| 14:07:35 | dom96_ | I feel that I should write my own GtkSourceView-like widget. GtkSourceView isn't flexible enough. |
| 14:18:37 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:27:27 | Jehan_ | Araq, dom96: Looks like the Aporia thing is actually a Nim<->C varargs interaction bug. |
| 14:27:51 | Jehan_ | Basically, gtk_list_store_new() expects a varargs list of longs. |
| 14:27:58 | Jehan_ | But Nim passes them as ints. |
| 14:28:25 | Jehan_ | These are basically enums, so Gtk can't tell and returns NULL. |
| 14:29:38 | Jehan_ | If I put the constant in a variable first, the variable has the proper type and size and gets passed correctly. |
| 14:35:57 | dom96_ | Does Aporia then work? |
| 14:36:02 | dom96_ | Can we fix this in the wrapper? |
| 14:39:23 | gokr2 | later |
| 14:39:28 | * | CARAM_ quit (Ping timeout: 272 seconds) |
| 14:39:31 | * | gokr2 quit (Quit: Leaving.) |
| 14:41:37 | Jehan_ | dom96: Yeah, it works now. And I think it's a compiler bug actually. |
| 14:45:16 | * | relumelu quit (Ping timeout: 246 seconds) |
| 14:47:48 | * | Boscop quit (Read error: Connection reset by peer) |
| 14:48:07 | Jehan_ | Ah, interesting, it may actually be a C compiler thing. |
| 14:48:12 | * | Boscop joined #nimrod |
| 14:50:52 | Jehan_ | Ah, yes, looks like a clang bug. |
| 14:52:22 | Jehan_ | That said, the reason that it works with gcc is really only luck. |
| 14:58:37 | dom96_ | Jehan_: cool |
| 14:58:55 | Jehan_ | dom96: Basically, here's what happens. |
| 14:59:24 | Jehan_ | Nim calls gtk_list_store_new((int) 6, 64, 64, 64, 64, 64, 64); |
| 14:59:38 | Jehan_ | But instead of each 64 there should be a 64L. |
| 14:59:44 | Jehan_ | Or (long) 64. |
| 14:59:57 | Jehan_ | The problem is that this is a C varargs function. |
| 15:00:23 | Jehan_ | int is 32 bits, long is 64 bits on my Mac (and this may be an issue on 64-bit Linux, too). |
| 15:00:53 | Jehan_ | So, the function reads two 32-bit arguments as a single 64-bit argument. |
| 15:02:09 | Jehan_ | Normally, gcc and clang see that this function has a varargs prototype, however, and pad short words to 64 bits, it appears. |
| 15:02:30 | Jehan_ | Except in the case of Aporia, it's a dynamically linked library, so the function is actually a function pointer. |
| 15:02:53 | Jehan_ | And it appears as though clang in this case forgets about it. |
| 15:03:20 | * | jorma joined #nimrod |
| 15:03:35 | Jehan_ | The gcc frontend to clang handles it correctly, though, it appears. |
| 15:03:40 | Jehan_ | Or rather, conservatively. |
| 15:03:49 | Jehan_ | Strictly speaking, what clang does is still correct. |
| 15:04:01 | Jehan_ | Nim should properly cast these constants to long. |
| 15:05:49 | Jehan_ | In any event, Aporia works if you compile with gcc for that reason. |
| 15:06:23 | Jehan_ | It's a bit ugly, and having to use Control rather then the Command key is not overly exciting, but it works. |
| 15:06:34 | dom96_ | So it's a nim compiler bug then? |
| 15:07:04 | Jehan_ | Yeah. |
| 15:07:14 | Jehan_ | Just one that manifests only under rare circumstances. |
| 15:07:49 | Araq | hi jorma welcome |
| 15:09:06 | Araq | Nim compiler is actually preferable. That should be easy to fix then. |
| 15:11:26 | Jehan_ | Mind you, what clang appears to be doing is not entirely kosher, either, and may break under other circumstances. I'll have to look into that later. |
| 15:11:31 | * | gokr_ joined #nimrod |
| 15:13:46 | * | gokr quit (Ping timeout: 258 seconds) |
| 15:15:28 | Jehan_ | Ah, I see, it's actually only the last argument that breaks. |
| 15:15:44 | Jehan_ | clang also stores 32-bit sized arguments, but doesn't zero out the underlying storage. |
| 15:16:53 | Jehan_ | So the upper bits of the last argument are garbage. |
| 15:32:29 | Jehan_ | I've submitted a bug report with code to reproduce the issue. |
| 15:33:12 | dom96_ | Jehan_: Awesome :D |
| 15:40:31 | * | kemet joined #nimrod |
| 15:41:52 | * | kemet quit (Client Quit) |
| 15:55:02 | * | Trustable joined #nimrod |
| 15:57:05 | * | fowl quit (Ping timeout: 258 seconds) |
| 15:58:04 | * | jorma quit (Ping timeout: 246 seconds) |
| 16:06:24 | * | endou_____ joined #nimrod |
| 16:15:56 | * | CARAM_ joined #nimrod |
| 16:16:51 | * | rpag joined #nimrod |
| 16:19:22 | * | flaviu is now known as flaviu_ |
| 16:21:33 | * | AMorpork is now known as AFKMorpork |
| 16:30:43 | * | gokr joined #nimrod |
| 16:31:46 | Araq | ugh, Jehan_ can you also look into: [csources] Build fail on OSX 64bit (#5) please? |
| 16:31:51 | * | gnosis_ joined #nimrod |
| 16:32:11 | Jehan_ | Araq: Link? |
| 16:32:35 | Araq | https://github.com/nimrod-code/csources/issues/5 |
| 16:32:39 | * | gokr_ quit (Ping timeout: 244 seconds) |
| 16:34:13 | Jehan_ | Hmm, I can reproduce the error, but I'm wondering what's happening here. |
| 16:39:04 | Jehan_ | Breaks on Linux, too. |
| 16:39:52 | Jehan_ | If I do a fresh "koch csource -d:release" on the most recent devel checkout (after having fixed the mingw issue), it works. |
| 16:40:32 | Araq | hrm works for me on linux, but I'm on the wrong branch |
| 16:42:21 | Jehan_ | I'm getting: |
| 16:42:25 | Jehan_ | c_code/2_2/nimrod.o: In function `PreMainInner': |
| 16:42:25 | Jehan_ | nimrod.c:(.text+0x9c1): undefined reference to `stdlib_cpuinfoDatInit' |
| 16:42:25 | Jehan_ | nimrod.c:(.text+0xaa7): undefined reference to `HEX00_prettybaseDatInit' |
| 16:42:25 | Jehan_ | nimrod.c:(.text+0xb6a): undefined reference to `HEX00_semparallelDatInit' |
| 16:42:25 | Jehan_ | nimrod.c:(.text+0xbec): undefined reference to `stdlib_cpuinfoInit' |
| 16:42:26 | Jehan_ | nimrod.c:(.text+0xcd2): undefined reference to `HEX00_prettybaseInit' |
| 16:42:26 | Jehan_ | nimrod.c:(.text+0xd95): undefined reference to `HEX00_semparallelInit' |
| 16:42:27 | Jehan_ | c_code/2_2/stdlib_osproc.o: In function `nospcountProcessors': |
| 16:42:27 | Jehan_ | stdlib_osproc.c:(.text+0x1714): undefined reference to `ncpicountProcessors' |
| 16:42:28 | Jehan_ | c_code/2_2/lookups.o: In function `skipalias_293255': |
| 16:42:28 | Jehan_ | lookups.c:(.text+0x9c6): undefined reference to `replacedeprecated_292324' |
| 16:42:29 | Jehan_ | c_code/2_2/cgen.o: In function `genmagicexpr_569274': |
| 16:42:29 | Jehan_ | cgen.c:(.text+0x17b5d): undefined reference to `liftparallel_477918' |
| 16:42:30 | Jehan_ | collect2: ld returned 1 exit status |
| 16:43:23 | Jehan_ | That's a fresh clone & sh build.sh |
| 16:46:14 | Jehan_ | Can grep build.sh, some modules such as semcall are never compiled or linked. |
| 16:46:54 | Jehan_ | Hmm, wait, that may be normal even. |
| 16:49:02 | Jehan_ | I also think that the c_code directories have old files in them that weren't removed. |
| 16:49:26 | Jehan_ | I usually do a rm -rf build/c_code before running koch csource |
| 16:51:08 | * | gokr quit (Ping timeout: 258 seconds) |
| 16:51:53 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 17:00:07 | Araq | yeah same here for 'master' |
| 17:00:11 | * | ehaliewicz joined #nimrod |
| 17:00:28 | Araq | so never mind, I will fix it |
| 17:01:11 | Jehan_ | It's three files that are missing: stdlib_cpuinfo, semparallel, and prettybase. |
| 17:01:20 | Jehan_ | Not sure why code for them wasn't generated. |
| 17:02:15 | Araq | well I simply forgot to commit build.sh ... :-( |
| 17:03:52 | * | Onionhammer quit (Ping timeout: 244 seconds) |
| 17:04:24 | * | flaviu_ quit (Remote host closed the connection) |
| 17:05:59 | * | flaviu joined #nimrod |
| 17:06:47 | * | Onionhammer joined #nimrod |
| 17:07:27 | Jehan_ | Ah. :) |
| 17:07:57 | Araq | koch needs a "push csources" command |
| 17:09:44 | NimBot | nimrod-code/csources master ddcc0f3 Araq [+0 ±1 -0]: fixes #5 |
| 17:11:00 | Jehan_ | Works now. :) |
| 17:11:24 | Araq | this csources repo still isn't ideal |
| 17:12:10 | Araq | but oh well, the alternatives all have their own problems |
| 17:12:11 | Jehan_ | In what way? Okay, it's a bit hackish, but in principle, it works. |
| 17:12:34 | Jehan_ | The only problem I'm seeing is that there's always a huge delta between commits. |
| 17:13:00 | Jehan_ | So the size blows up fairly fast. |
| 17:13:11 | Araq | that will vanish with the planned "deterministic C code generation" feature |
| 17:13:29 | Araq | plus we can always prune history |
| 17:14:32 | Jehan_ | Yeah. |
| 17:17:06 | Jehan_ | I've been working on how to make a smaller source distribution that's still not dependent on tools like xz. |
| 17:17:31 | Jehan_ | What seems to work is to tar each c_code subdirectory individually and then generate binary diffs between successive tars. |
| 17:18:53 | Jehan_ | I'd just have to modify bsdiff/bspatch to not use bzip2. |
| 17:36:15 | irrequietus | Araq: using nimrod with some C bindings for interfacing to hardware :) |
| 17:37:17 | irrequietus | because it compiles to sweet C this might be indeed my work use now, heh :D |
| 17:51:32 | * | boydgreenfield joined #nimrod |
| 18:00:59 | * | Fran__ quit (Quit: Leaving) |
| 18:01:22 | * | Matthias247 joined #nimrod |
| 18:01:42 | * | Fr4n joined #nimrod |
| 18:14:47 | ldlework | If I wanted to look at the definition of pop for sequences where would I look? |
| 18:15:00 | ldlework | (the docs should link to the source, that'd be amazing) |
| 18:15:23 | dom96_ | Pretty sure they do link to the source. |
| 18:15:43 | dom96_ | You can also look at the index and Ctrl + F "pop" |
| 18:15:48 | Jehan_ | It's in lib/system.nim |
| 18:15:48 | ldlework | http://nimrod-lang.org/system.html#pop,seq[T] |
| 18:16:36 | ldlework | thanks |
| 18:16:49 | Araq | dom96_: I had to disable the link to source feature for 0.9.6 |
| 18:16:57 | Araq | it broke and I dunno why |
| 18:17:01 | * | bjz_ quit (Read error: Connection reset by peer) |
| 18:17:17 | * | bjz joined #nimrod |
| 18:21:54 | * | Boscop quit (Ping timeout: 265 seconds) |
| 18:22:31 | * | askatasuna joined #nimrod |
| 18:24:03 | ldlework | if I wanted to contribute, say, https://gist.github.com/dustinlacewell/61f3ccbc4e36dd1d0952 to the system library, how does that work, would it be rejected because it is too simple, etc? |
| 18:24:51 | * | irrequietus quit () |
| 18:26:13 | * | ehaliewicz quit (Ping timeout: 255 seconds) |
| 18:27:09 | Araq | ldlework: it's acceptable for sequtils |
| 18:27:18 | Araq | system.nim is already too bloated |
| 18:27:25 | ldlework | Araq: oh neat |
| 18:27:33 | Araq | so I don't accept anything for it, unless I can't avoid it |
| 18:27:51 | Jehan_ | I think there has to be a better name than ipop, though. :) |
| 18:29:39 | Araq | yeah, plus 'del' results not in intuitive semantics |
| 18:30:15 | Araq | 'ipop' needs to keep the order, otherwise the seq is not stack-like |
| 18:30:24 | Araq | so you have to use 'delete' |
| 18:32:44 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 18:32:49 | ldlework | Araq: oh when reading over it I thought delete was just an alias |
| 18:33:55 | ldlework | Jehan_: suggestion? |
| 18:34:19 | ldlework | I mean should probably just modify the actual pop to take an optional index |
| 18:34:19 | Jehan_ | Umm, it's something that should really be consistent across the library. |
| 18:34:25 | Jehan_ | For get-and-remove functionality. |
| 18:35:30 | Jehan_ | extractAt() or something like that sounds intuitive. |
| 18:35:50 | * | boydgreenfield joined #nimrod |
| 18:36:06 | * | Boscop joined #nimrod |
| 18:36:11 | ldlework | takeAt ? |
| 18:36:17 | * | gnosis_ quit (Quit: Connection closed for inactivity) |
| 18:36:22 | ldlework | or just 'take' |
| 18:36:53 | * | Boscop_ joined #nimrod |
| 18:37:35 | ldlework | Jehan_: Nim supports proc overloading right? |
| 18:37:46 | ldlework | Couldn't we just implement another pop that supports the index? |
| 18:37:57 | * | BitPuffin joined #nimrod |
| 18:38:11 | Jehan_ | Hmm. |
| 18:38:24 | Araq | sounds like a good solution |
| 18:38:29 | Jehan_ | The answer is, yes, it does. Not sure if `pop` is still meaningful in this context, though. |
| 18:38:53 | ldlework | Jehan_: https://docs.python.org/2/tutorial/datastructures.html |
| 18:39:05 | Araq | the real question is what do you need ipop for? |
| 18:39:28 | ldlework | Araq: nothing, I'm just perusing the documentation, and writing little tests here and there |
| 18:39:35 | Jehan_ | ldlework: Umm, some of Python's naming choices are not necessarily great. |
| 18:40:01 | ldlework | Jehan_: its not necessarily terrible, pop that is |
| 18:40:29 | ldlework | No one is going to say, what the hell is with nimrod, they gave their pop function an index! :) |
| 18:40:49 | * | Boscop quit (Ping timeout: 265 seconds) |
| 18:43:15 | ldlework | Araq: wait, would that still go in sequtils? |
| 18:43:47 | Araq | ldlework: yeah, but then the old pop will be moved over there too |
| 18:43:57 | ldlework | Araq: okay! |
| 18:44:00 | Araq | in fact, I should do that for bigbreak already |
| 18:44:23 | ldlework | Araq: what is bigbreak |
| 18:44:47 | Araq | version 0.10.0 to be released |
| 18:44:49 | ldlework | is there a document outlining the branching business |
| 18:44:52 | ldlework | oh |
| 18:45:02 | ldlework | Araq: I'll submit the pr for it |
| 18:45:06 | ldlework | against bigbreak? |
| 18:45:10 | Araq | ldlework: yep |
| 18:45:13 | ldlework | k |
| 18:45:20 | Araq | er wait a sec |
| 18:45:29 | Araq | did we decide it's necessary? |
| 18:45:33 | * | superfunc joined #nimrod |
| 18:49:34 | Jehan_ | Hmm, is there something wrong with idetools on bigbreak? |
| 18:50:00 | ldlework | Araq: well, is pop necessary? |
| 18:50:09 | ldlework | I mean its only 3 lines. |
| 18:50:22 | ldlework | sequtils seems fine to contain such helpers? |
| 18:50:54 | Araq | ldlework: pop is not necessary but has the benefit of already existing |
| 18:51:06 | Jehan_ | nim idetools does not do anything where nimrod idetools works with the exact same arguments. |
| 18:51:28 | ldlework | Araq: I can submit it or not, it was just an idea. |
| 18:51:47 | ldlework | It would be pretty cool to be a contributor! :P |
| 18:52:14 | Araq | fix one of the over 300 issues then |
| 18:52:38 | dom96_ | Araq: Has bigbreak been merged into devel yet? |
| 18:52:53 | Araq | dom96_: no |
| 18:53:08 | dom96_ | will it be? |
| 18:53:23 | Araq | next week perhaps |
| 18:55:05 | NimBot | Araq/Nimrod bigbreak fdf9969 Araq [+0 ±3 -0]: implements #1588 |
| 18:55:05 | NimBot | Araq/Nimrod bigbreak 7a48942 Araq [+0 ±9 -0]: nicer error messages (untested) |
| 18:57:17 | * | Boscop joined #nimrod |
| 18:57:18 | * | Boscop quit (Changing host) |
| 18:57:18 | * | Boscop joined #nimrod |
| 19:00:48 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:01:32 | * | Boscop_ quit (Ping timeout: 245 seconds) |
| 19:04:05 | ldlework | I'm confused, the readline proc's in system.nim are empty? |
| 19:05:06 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 19:05:17 | * | johnsoft joined #nimrod |
| 19:07:26 | Jehan_ | ldlework: It's a forward declaration. |
| 19:07:37 | ldlework | ah |
| 19:10:29 | * | gokr joined #nimrod |
| 19:10:51 | * | boydgreenfield joined #nimrod |
| 19:12:28 | ldlework | Would a solution to this ticket be a pr that adds generic versions of all the float specific functions casting to float then back to the generic type? https://github.com/Araq/Nimrod/issues/562 |
| 19:13:15 | Araq | ldlework: also update web/news.txt and document it as a breaking change |
| 19:13:49 | ldlework | Araq: for the math.nim one, or the one I submitted against pop? |
| 19:13:59 | * | irrequietus joined #nimrod |
| 19:14:42 | Araq | the latter |
| 19:15:01 | ldlework | ok |
| 19:15:18 | Araq | ldlework: what's the point of generic floating point ops where "generic" means either float32 or float64? |
| 19:15:41 | ldlework | Araq: I think the guy in the PR wants to be able to do sqrt(an_int) |
| 19:15:44 | * | askatasuna quit (Quit: WeeChat 1.0.1) |
| 19:15:54 | Araq | that's stupid |
| 19:15:59 | ldlework | instead of int(sqrt(float(i)) |
| 19:16:12 | ldlework | is it? |
| 19:16:30 | ldlework | seems like with generic versions, the math api would be pretty nice |
| 19:16:46 | ldlework | Does nim have generics constraints |
| 19:17:00 | ldlework | where you can say, T must have this or that trait for being converted to and from float? |
| 19:17:28 | * | xcombelle joined #nimrod |
| 19:19:48 | ldlework | proc sqrt*(x: T): T = result = T(sqrt(float(x))) # does this work? |
| 19:20:49 | ldlework | heh if I'm being stupid just say so, I know I don't know what I'm doing |
| 19:27:13 | * | Demos joined #nimrod |
| 19:27:44 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:27:48 | * | gokr1 joined #nimrod |
| 19:28:15 | Jehan_ | ldlework: That does not necessarily have sane semantics. |
| 19:28:25 | gokr1 | evening |
| 19:28:42 | Jehan_ | I'd do a proc(x: BiggestInt): float = sqrt(float(x)) or something like that. |
| 19:28:49 | Jehan_ | But don't cast back to the integral type. |
| 19:30:20 | Jehan_ | sqrt(2) isn't 1. |
| 19:31:56 | Araq | philosophically speaking, sqrt(2) isn't even a number. It's an algorithm. ;-) |
| 19:34:53 | Jehan_ | Huh? It's very much a real number. |
| 19:35:10 | Jehan_ | Well, the floating point approximation is only a rational number, but it's still a number. |
| 19:36:42 | Araq | well it's an irrational number. |
| 19:37:24 | Araq | it's decimal representation is infinite, and as a constructivist I reject its existance ;-) |
| 19:37:25 | Jehan_ | Which was an issue only for the old Greeks. |
| 19:37:28 | Araq | *its |
| 19:37:43 | Araq | no, it should be an issue for any computer scientist |
| 19:38:07 | Jehan_ | Its existence is not a problem for constructivist math. |
| 19:38:41 | Jehan_ | The thing is, without irrational numbers you cannot have calculus (or any sane form of it). |
| 19:39:14 | Araq | well sqrt(2) is definitely more abstract than 2 |
| 19:39:20 | Araq | or 1/2 |
| 19:40:04 | Araq | if you keep it as sqrt(2) and not expand it, it causes no problems for constructivists, I guess |
| 19:41:15 | gokr1 | Call me stupid, but why does "echo $x.size" not work (a tuple with an int) but "echo `$`x.size" does? |
| 19:41:49 | gokr1 | And "echo($x.size)" works too. |
| 19:42:00 | Araq | it's parsed as (echo) $ (x.size) |
| 19:42:12 | Araq | binary $ |
| 19:42:27 | Araq | it works when you use #! strongSpaces |
| 19:42:27 | gokr1 | oooh. |
| 19:43:16 | gokr1 | And why did it work ... with `$`? |
| 19:43:31 | Jehan_ | Because `$` is an identifier, not an operator. |
| 19:43:41 | Jehan_ | You can't write 1 `+` 2, either. |
| 19:43:48 | Jehan_ | But you can write 1.`+`(2) |
| 19:48:38 | gokr1 | There is no equivalence to a cascade in Nim, right? Although trivial I guess with macros |
| 19:54:08 | Jehan_ | What do you mean by cascade specifically? Sorry, the term is a bit overloaded. |
| 19:54:51 | gokr1 | A Smalltalk cascade. In Smalltalk I can do "x add(5);add(6)" which is equivalent to "x add(5). x add(6)" |
| 19:55:02 | gokr1 | So sending a series of messages to the same receiver. |
| 19:55:23 | Jehan_ | Gotcha. And yes, macros work for that. |
| 20:08:19 | * | wan quit (Ping timeout: 244 seconds) |
| 20:10:29 | * | ehaliewicz joined #nimrod |
| 20:15:20 | * | ehaliewicz quit (Ping timeout: 244 seconds) |
| 20:19:45 | dom96_ | hrm. Can't seem to be able to install GTK through homebrew. |
| 20:19:49 | dom96_ | Jehan_: How did you do it? |
| 20:20:03 | dom96_ | I'm getting an error when it tries to run make install. |
| 20:22:30 | Jehan_ | dom96_: How did I do what? |
| 20:22:48 | Jehan_ | Oh, gtk+? |
| 20:23:04 | Jehan_ | I just did brew install gtk+, I think. |
| 20:23:20 | Jehan_ | Mind you, I'm still running Mountain Lion, which has an older clang version. |
| 20:23:47 | * | BlaXpirit joined #nimrod |
| 20:25:38 | * | Ven joined #nimrod |
| 20:26:13 | dom96_ | Jehan_: This mac has an even older OS: Lion. |
| 20:26:22 | dom96_ | Maybe that's why it fails :\ |
| 20:27:04 | * | ehaliewicz joined #nimrod |
| 20:27:16 | * | ehaliewicz quit (Remote host closed the connection) |
| 20:27:29 | * | Ven quit (Client Quit) |
| 20:27:52 | Jehan_ | Hmm. No idea. |
| 20:33:06 | gokr1 | If I am making a standard object "constructor" - I can either use the predefined result guy and set attributes on him, or I can just use the object construction syntax. What is the ... normal way? |
| 20:33:46 | gokr1 | I mean say: proc newBoat2(color: string, size: int): Boat = Boat(color: color, size: size) |
| 20:34:04 | gokr1 | or: proc newBoat(color: string, size: int): Boat = result.color = color; result.size = size |
| 20:38:10 | Araq | flaviu: https://github.com/Araq/Nimrod/issues/1217 is still open? |
| 20:38:55 | flaviu | Nope. It looks like I didn't use the keywords github looks for in the commit message. |
| 20:39:06 | Araq | gokr1: the first way has more advantages, so if possible, you should use that |
| 20:39:30 | gokr1 | There is no... double allocation going on then, right? |
| 20:40:01 | Araq | the 2nd way is used more often I think for the simple reason that it existed much earlier |
| 20:40:11 | gokr1 | This result guy... feels funky. But I suspect that its only when I use him, that he gets allocated? |
| 20:40:17 | flaviu | gokr1: The second version would crash at runtime if Boat was a pointer. |
| 20:40:29 | flaviu | Unless I'm horribly wrong again :P |
| 20:41:50 | * | q66[lap] joined #nimrod |
| 20:41:50 | * | q66[lap] quit (Client Quit) |
| 20:44:12 | Jehan_ | If it's a ref object, you first have to call new(result). |
| 20:45:15 | Araq | gokr1: 'result' is very handy and not in any way novel. both Delphi and Eiffel have it. One point of it is to encourage decoupling setting the return value from control flow |
| 20:47:35 | gokr1 | flaviu: You are correct. I just changed Boat to a ref object, and yes, Illegal storage access. |
| 20:50:10 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 20:50:12 | Araq | yes because you need to do 'new(result)' |
| 20:50:21 | gokr1 | And inserting the "new(result)" fixed it, so indeed - result is ... just a correctly typed "local" var, no allocation going on. |
| 20:54:18 | Araq | guys can somebody please look into web/babelpkglist.nim and see why the "If you are reading this you..." div is not properly replaced? |
| 20:54:33 | Araq | ping Varriount |
| 20:55:06 | * | wan joined #nimrod |
| 20:55:11 | Araq | the div is in doc/lib.txt |
| 20:56:22 | ldlework | When I try to compile bigbreak I get, https://gist.github.com/dustinlacewell/61b0697c5311c29ce2a8 |
| 20:57:10 | Araq | ldlework: csources from bigbreak too? |
| 20:57:17 | ldlework | I'll make sure |
| 21:00:38 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 21:01:18 | * | johnsoft joined #nimrod |
| 21:15:59 | gokr1 | it seems procs resolve first, then methods, correct? |
| 21:16:39 | gokr1 | Mmm, right, so during compilation - if we can find a proc - then we just statically bind that. Logical. |
| 21:18:09 | gokr1 | Its a pretty nifty mix, so usually I guess you code away with inheritance of objects and overloaded procs - as long as it works out, right? |
| 21:19:28 | Jehan_ | gokr1: More often, you'll use parametric polymorphism and variant types. |
| 21:20:31 | Jehan_ | E.g. proc foo[T](x: T) instead of proc foo(x: S) |
| 21:20:46 | gokr1 | So, right... many smaller object hierarchies can easily be described with variants. And then... ah, generics you mean. |
| 21:21:50 | Jehan_ | Yeah, but my point is that parametric polymorphism is polymorphism as an alternative to subtype polymorphism. |
| 21:22:05 | * | irrequietus quit () |
| 21:22:25 | Jehan_ | You use the former where you can do static dispatch, the latter where you need dynamic dispatch. |
| 21:22:56 | Jehan_ | Parametric polymorphism gives you better type information, subtype polymorphism the flexibility of late binding. |
| 21:33:04 | gokr1 | Since I am a bit rusty on generics stuff - in this case Nim will compile several variants of foo (your example) - given all callsites of foo, right? |
| 21:34:25 | gokr1 | So instead of "losing" type info with using a common type for a parameter - and thus not being able to bind statically anymore in that proc - you use that. |
| 21:34:49 | gokr1 | (not so eloquently put, but) |
| 21:35:47 | * | xcombelle quit (Ping timeout: 265 seconds) |
| 21:37:44 | Jehan_ | Yes, though in principle a shared implementation is also possible. |
| 21:37:58 | Jehan_ | Similar to what OCaml and Haskell do. |
| 21:38:38 | gokr1 | Yeah, right. |
| 21:43:02 | * | wan quit (Ping timeout: 265 seconds) |
| 21:49:43 | NimBot | Araq/Nimrod bigbreak 0e439ce Araq [+3 ±2 -1]: implements #78 |
| 21:52:24 | * | Jesin quit (Quit: Leaving) |
| 21:52:30 | gokr1 | Btw, wxRust piggy backs on the work by wxHaskell to produce a C wrapper of wx. https://github.com/kenz-gelsoft/wxRust |
| 21:52:56 | gokr1 | Then they generate a "high level binding" using a Python script. |
| 22:03:36 | ldlework | Araq: when compiling a hello world after compiling bigbreak: https://gist.github.com/dustinlacewell/a7910033a66a1ff20d72 |
| 22:04:51 | gokr1 | ldlework: I think Araq fixed that one... the other day. |
| 22:05:02 | gokr1 | Check IRC log :) |
| 22:07:22 | Araq | ldlework: should work with today's commits |
| 22:07:31 | ldlework | I just cloned |
| 22:07:35 | ldlework | gar |
| 22:07:49 | Araq | well don't use 0.9.6 to build it, it won't work |
| 22:08:29 | Araq | gokr1: yeah, I used the C wrapper of wx too. |
| 22:16:24 | * | wan joined #nimrod |
| 22:23:07 | * | xenagi joined #nimrod |
| 22:28:50 | Araq | looks like I need a bigbreak-devel branch ... |
| 22:29:06 | gokr1 | An object adds a header that has a ref to the type of the object (I guess) - but.. is there more? I am guessing a tuple has nothing in addition to its members. |
| 22:29:33 | Araq | a raw object also has no runtime type information (RTTI) |
| 22:29:45 | Araq | it's introduced when you do "object of ...." |
| 22:29:56 | gokr1 | Right, yes, I read that. |
| 22:30:08 | gokr1 | Or {.inheritable.} |
| 22:30:15 | Araq | true |
| 22:30:29 | gokr1 | But ... I think its also mentioned that objects have "hiding" and tuples do not. |
| 22:30:48 | gokr1 | But this ... is just a "design choice" or? |
| 22:31:06 | gokr1 | I presume its about the "*". |
| 22:31:17 | * | superfun[c] joined #nimrod |
| 22:31:49 | Araq | how can you reasonably hide fields in a tuple? |
| 22:32:05 | Varriount | Araq: Pong |
| 22:32:19 | Araq | Varriount: I see no patch to koch.nim wrt version detection |
| 22:33:24 | Varriount | Araq: Did you look in the bigbreak branch? |
| 22:33:29 | gokr1 | Sidenote: On the GDB/MI stuff, there seems to be two C libs, but... don't seem to be in very useful states. gdbwire and libmigbd |
| 22:36:22 | Araq | Varriount: I missed your import, that's ugly :P |
| 22:36:42 | Araq | and also wrong |
| 22:37:08 | Araq | or let's say slightly less wrong than system.NimVersion |
| 22:37:14 | Araq | but still not correct |
| 22:37:25 | Araq | the point is that koch is not recompiled often |
| 22:37:42 | Araq | so koch needs to read the version from Nim *at runtime* |
| 22:38:02 | * | nande joined #nimrod |
| 22:38:22 | * | boydgreenfield joined #nimrod |
| 22:40:17 | Varriount | Araq: But where will it read the version from? |
| 22:40:52 | Varriount | Should we open up nversion.nim, read in the contents, and get the version from there? |
| 22:40:56 | gokr1 | Araq: On reasonably hiding in tuples - to me they don't look that different to objects. But I agree - there are a range of convenience things that would make it "oddish" - you can index via [i], you can unpack in let/var, you can create a tuple without a declared type. |
| 22:42:12 | Araq | Varriount: I thought about running the compiler and extracting the version number it reports |
| 22:42:56 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:43:03 | Varriount | Araq: If I'm compiling version 9.6 with version 9.5, 9.5 is going to report its version as 9.5 |
| 22:44:16 | Varriount | Araq: We could have koch compile itself when bootstrapping. :p |
| 22:44:26 | Araq | Varriount: how so? the compiler itself takes the number from nversion.nim |
| 22:44:44 | Araq | koch passes the version only to the docgen etc. |
| 22:45:35 | Varriount | Oh, I see. I was thinking wrongly. |
| 22:46:02 | Jehan_ | Hmm, there doesn't seem to be a string reverse function in the stdlib. Or am I just overlooking something? |
| 22:46:29 | Araq | it's perhaps not exported, Jehan_ |
| 22:46:52 | Jehan_ | Hmm, I was going through strutils.nim in its entirety. |
| 22:47:30 | * | Jesin joined #nimrod |
| 22:53:51 | Araq | Varriount: btw I skimmed your bugfix about the missing * export marker. looks good. |
| 22:53:59 | Araq | did you already make a PR? |
| 22:54:59 | Araq | and what is 'kickstart'? |
| 22:58:28 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 22:59:25 | * | johnsoft joined #nimrod |
| 23:00:36 | * | gokr quit (Quit: IRC for Sailfish 0.8) |
| 23:06:15 | Trustable | Is the branch "master" the replacement for "stable"? |
| 23:06:24 | Trustable | https://github.com/Araq/Nimrod/wiki/Official-branches |
| 23:07:06 | flaviu | Araq: reverse isn't in there. It is available in algorithm.nim, but only for openarrays |
| 23:08:49 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 23:09:19 | Araq | Trustable: "stable" means pretty much "dead", but yes |
| 23:09:58 | Trustable | Araq: Should "stable" replaced by "master" in this wiki page? |
| 23:11:41 | * | boydgreenfield joined #nimrod |
| 23:12:40 | * | Boscop_ joined #nimrod |
| 23:12:59 | NimBot | Araq/Nimrod bigbreak 73ff043 Araq [+0 ±2 -0]: docgen works on linux |
| 23:15:22 | Araq | who writes these wiki pages? |
| 23:15:46 | Araq | and should I read them? |
| 23:16:27 | * | Boscop__ joined #nimrod |
| 23:16:32 | * | Boscop quit (Ping timeout: 255 seconds) |
| 23:19:02 | Trustable | I have marked it as outdated |
| 23:20:29 | Araq | it describes perhaps the way it should be done |
| 23:20:31 | * | Boscop_ quit (Ping timeout: 255 seconds) |
| 23:21:17 | Araq | Varriount: can you look into the babelpckglist.nim issue please? |
| 23:22:26 | Araq | good night |
| 23:22:35 | * | Boscop__ quit (Ping timeout: 244 seconds) |
| 23:26:53 | Trustable | good night |
| 23:31:31 | * | fowlmouth joined #nimrod |
| 23:36:04 | * | saml_ joined #nimrod |
| 23:44:12 | * | superfun[c] quit (Quit: Page closed) |
| 23:46:04 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:58:26 | * | superfun[c] joined #nimrod |
| 23:58:33 | * | darkf joined #nimrod |