| 01:32:44 | dom96 | OrionPK: Any luck? |
| 01:33:59 | * | DAddYE quit (Remote host closed the connection) |
| 01:36:24 | OrionPK | dom96: nope, had to do real world shit for a couple hours |
| 01:36:58 | OrionPK | it's having troubles with these "cd && git" commands i think |
| 01:37:24 | OrionPK | not that the cd or the && is the issue, but the git clone works fine |
| 01:40:33 | dom96 | hrm. ok. Let me know if you figure anything else out. I will look into it once I get all the wanted functionality into babel for a 0.1 release. |
| 01:41:06 | OrionPK | k, will do |
| 01:42:41 | EXetoC | stupid real world! |
| 01:56:31 | OrionPK | I know right |
| 02:03:59 | * | Trixar_za is now known as Trix[a]r_za |
| 02:12:15 | dom96 | good night |
| 02:18:01 | * | Trix[a]r_za is now known as Trixar_za |
| 02:22:16 | * | Trixar_za is now known as Trix[a]r_za |
| 02:24:01 | OrionPK | dom96 can we switch to using "setCurrentDir" instead of "cd &&"s? |
| 02:27:10 | OrionPK | I think I have it working |
| 02:35:16 | * | DAddYE joined #nimrod |
| 02:41:47 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 02:49:49 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 03:08:07 | * | DAddYE joined #nimrod |
| 03:43:51 | * | DAddYE quit (Read error: Connection reset by peer) |
| 03:46:32 | reactormonk | OrionPK, it compiles? |
| 03:46:41 | * | OrionPK quit (Quit: Leaving) |
| 03:47:52 | * | DAddYE joined #nimrod |
| 04:52:53 | * | DAddYE_ joined #nimrod |
| 04:52:53 | * | DAddYE quit (Read error: Connection reset by peer) |
| 04:54:41 | * | DAddYE joined #nimrod |
| 04:54:41 | * | DAddYE_ quit (Read error: Connection reset by peer) |
| 05:17:44 | * | fowl quit (Quit: EliteBNC free bnc service - http://elitebnc.org) |
| 05:26:26 | * | fowl joined #nimrod |
| 05:30:30 | * | fowl quit (Client Quit) |
| 05:45:59 | * | fowl joined #nimrod |
| 06:23:57 | * | DAddYE quit (Remote host closed the connection) |
| 07:07:49 | * | Araq_ joined #nimrod |
| 07:47:13 | * | fowl quit (Quit: EliteBNC free bnc service - http://elitebnc.org) |
| 07:50:53 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 08:11:51 | * | gradha joined #nimrod |
| 08:35:30 | * | fowl joined #nimrod |
| 10:25:02 | * | Araq_ joined #nimrod |
| 10:50:29 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 10:52:57 | * | q66 joined #nimrod |
| 11:38:09 | * | EXetoC joined #nimrod |
| 12:04:20 | * | Araq_ joined #nimrod |
| 12:11:49 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 12:45:08 | * | Araq_ joined #nimrod |
| 12:47:50 | * | Araq_ quit (Client Quit) |
| 13:29:29 | * | bmp joined #nimrod |
| 13:30:14 | dom96 | hello bmp |
| 13:30:44 | bmp | Hi dom96 |
| 13:31:45 | EXetoC | HALLO |
| 13:35:39 | EXetoC | dom96: using Jester for anything practical? |
| 13:35:52 | dom96 | EXetoC: yep. The forum and nimbuild use it. |
| 13:36:11 | EXetoC | oh ok |
| 13:37:48 | EXetoC | it's nice when people actually use what they have developed *looks at Walter Bright* :-P |
| 13:38:33 | EXetoC | dom96: using the templating engine as well? |
| 13:38:33 | dom96 | yep. |
| 13:38:58 | dom96 | Damn |
| 13:39:53 | EXetoC | aight cool. will mess about with both later |
| 13:40:23 | dom96 | great. |
| 13:40:33 | * | dom96 is currently trying to fix something in it |
| 13:43:58 | EXetoC | good luck my friend |
| 13:44:43 | dom96 | thank you :P |
| 13:48:33 | EXetoC | c(:)-< |
| 13:51:23 | * | Araq_ joined #nimrod |
| 13:51:33 | dom96 | hrm, what should I name the proc which determines whether a socket has data in its send buffer? |
| 13:52:23 | Araq_ | no irclogs! |
| 13:52:33 | dom96 | I am aware. |
| 13:52:33 | Araq_ | and the logs of yesterday have been cut off again! |
| 13:52:43 | Araq_ | welcome bmp btw |
| 13:52:53 | dom96 | I am fixing that right now. |
| 13:52:53 | Araq_ | good. |
| 13:53:03 | Araq_ | I was about to complain about it |
| 13:53:13 | Araq_ | ;-) |
| 13:53:23 | dom96 | now, answer my question :P |
| 13:53:38 | EXetoC | (is)?dataAvailable |
| 13:53:48 | Araq_ | hasData |
| 13:53:48 | EXetoC | hasData? |
| 13:53:48 | EXetoC | :p |
| 13:53:58 | dom96 | I was thinking: isSendDataBuffered |
| 13:54:08 | EXetoC | hm |
| 13:54:18 | Araq_ | or maybe canSend? |
| 13:54:43 | Araq_ | "available" is too hard to type, EXetoC ;-) |
| 13:54:43 | dom96 | no, because you can still send regardless of whether data is buffered. |
| 13:55:58 | Araq_ | see you later |
| 13:55:58 | * | Araq_ quit (Client Quit) |
| 13:57:43 | dom96 | meh, i'll go with isSendDataBuffered |
| 14:07:38 | EXetoC | is that the same thing? what if it is buffered but currently has no data in it? |
| 14:08:03 | EXetoC | there are no generic container interfaces yet, right? |
| 14:08:13 | dom96 | is what the same thing? |
| 14:08:38 | EXetoC | dom96: buffered and has data |
| 14:09:18 | dom96 | yep, it's not. There are two buffers as well... |
| 14:11:03 | EXetoC | not sure what you mean, but nevermind. I've barely written any network code |
| 14:11:58 | dom96 | there is a buffer for received data (which is waiting to be processed) and a buffer for sent data (which is waiting to be sent) |
| 14:12:23 | EXetoC | right |
| 14:12:53 | dom96 | Asking whether a socket "hasData" is a bit vague. |
| 14:13:23 | EXetoC | ok |
| 14:17:43 | bmp | This is a dumb question, but what actually is the status with implicit paraentheses? The example on the home page uses them, but the rules for them aren't mentioned (or I can't find them) in the official docs, which also don't use them. |
| 14:18:23 | bmp | With the exception that the manual does say they're optional for parameterless methods, which wouldn't apply to the "echo" example on the home page. |
| 14:18:43 | dom96 | That's actually a good question. |
| 14:19:43 | bmp | In general, I like Nimrod syntax, incidentally; you did a good job merging Delphi, Python, Oberon, and a kind of Dylanesque thing into a langauge that still feels cohesive. |
| 14:19:53 | dom96 | Sadly, i'm not sure where this is documented. |
| 14:20:38 | gradha | bmp: I think the rule of thumb is to always use parenthesis, and then, from time to time, see if some code compiles after removing some |
| 14:21:43 | bmp | gradha: If that's the "rule of thumb," it seems like it'd be better to just mandate them. By saying you're not sure when they can be dropped, you're also tacitly admitting you wouldn't know where to put them if they were left off successfully by a previous developer. |
| 14:22:03 | bmp | Kind of like Common LIsp's LOOP construct, where most devs seem to just keep writing code until the thing compiles. :-/ |
| 14:23:03 | gradha | the language certainly knows where they are mandatory, but I don't, so I use that rule to explore what the language accepts as valid source code |
| 14:23:23 | EXetoC | eh, wasn't it in the manual just a couple of days ago? |
| 14:24:58 | EXetoC | the only limitation might very well be that the "command" syntax can't be nested for obvious reasons |
| 14:32:24 | fowl | bmp: u can leave off parens from a statement function call |
| 14:32:44 | fowl | Echo 1. For example |
| 14:33:24 | fowl | If u need to pass named args, a stmt list or do stmt they are required though |
| 14:34:39 | fowl | Even something like `someseq[2] f,y` is OK. Someseq holds functions |
| 14:37:04 | * | zahary_ left #nimrod (#nimrod) |
| 14:37:04 | * | zahary_ joined #nimrod |
| 14:38:14 | fowl | `func` will not call it, because afunction is a value, but `foo.func` will because this is actually `func foo` |
| 14:38:24 | fowl | Hope that clears things up |
| 14:45:19 | EXetoC | so, there's really no need for explicit member functions. proc f(x: int) ... f(1) ... 1.f() ... 1.f |
| 14:46:34 | gradha | correct |
| 14:47:14 | gradha | note how procs/methods are not bound to an object, the syntax makes it look so |
| 14:48:04 | fowl | Yea EXetoC though if f were a field on int, u would have to use f 1 to call it |
| 14:49:04 | fowl | Its really nice though, makes the flow of data much easier to read IMO |
| 14:49:39 | gradha | the language doesn't use this neither self as keywords, so you can emulate the look of C++ or python by naming the first parameter of a proc that way |
| 14:52:14 | fowl | That's a standard API to use, even a lot of c libraries follow that form |
| 14:52:54 | EXetoC | the only issue I've had with this kind of flexibility is giving something the same name as a keyword. I just ended up duplicating the last character |
| 14:53:24 | EXetoC | since underscores aren't significant. very minor issue, I know :> |
| 14:53:24 | EXetoC | a small price to pay |
| 14:54:19 | fowl | U can actuallyuse a keyword as an ide |
| 14:54:34 | fowl | Identifier but its painful to use |
| 14:54:34 | dom96 | you can wrap keywords in `` |
| 14:55:04 | EXetoC | right |
| 14:56:24 | bmp | I hate having to do that in C#; I'd definitely hope people avoid that in Nimrod, too, except where absolutely necessary. |
| 14:57:24 | gradha | some conventions mandate that procs/methods should use verb like names, so they don't conflict with variables which are more like nouns or adjectives |
| 14:58:44 | EXetoC | so plenty of 'get' prefixes then? :> |
| 14:59:24 | fowl | Nah u hardly ever need to do that |
| 15:00:04 | fowl | One use that comes to mind is luas lua_type func which is one of 2 lua functions left with the lua prefix on it |
| 15:00:24 | gradha | EXetoC: "get*" sounds more like a public accessor to a variable, maybe just name it like a variable then? |
| 15:03:30 | dom96 | !lag |
| 15:03:30 | NimBot | 1ms between me and the server. |
| 15:58:56 | gradha | hmm... php framework http://laravel.com beating ruby on rails? fascinating |
| 15:59:20 | gradha | dom96: how did the jester benchmark end up? |
| 16:02:04 | dom96 | gradha: They delayed the benchmarks until Tuesday :\ |
| 16:08:07 | fowl | gradha: that shouldn't surprise you, rails is notoriously slow |
| 16:41:07 | * | DAddYE joined #nimrod |
| 16:47:15 | EXetoC | dom96: have you had to written any platform-specific network code yet? |
| 16:51:02 | EXetoC | write even |
| 16:52:07 | dom96 | well, I wrote most of the network-related modules in the stdlib. But I guess that's not what you mean. |
| 16:53:38 | dom96 | The sockets and asyncio modules should work on all platforms. |
| 16:55:06 | EXetoC | yeah it's kinda necessary in library code |
| 17:22:22 | reactormonk | dom96, about #490: it tried to give you a longline warning and then broke upon int16 |
| 17:23:56 | dom96 | Right. I was in a hurry to fix nimbuild so I didn't look into the cause. |
| 17:56:46 | * | Sergio965 joined #nimrod |
| 18:02:36 | EXetoC | Sergio965: hello there, my good friend |
| 18:02:44 | Sergio965 | Hello! :) |
| 18:02:54 | EXetoC | not in #rust anymore? eeexcellent :> |
| 18:03:19 | Sergio965 | Lol. |
| 18:04:02 | Sergio965 | For now, at least. |
| 18:04:03 | Sergio965 | :) |
| 18:04:29 | EXetoC | huehue |
| 18:04:41 | dom96 | he's in #go-nuts though :P |
| 18:05:21 | Sergio965 | Thanks for keeping an eye out for me! :) |
| 18:11:32 | fowl | Should add a plugin to nimbot to sit in competitive channels and see who the traitors are |
| 18:11:53 | gradha | also perform IP matching to avoid renames confuse it |
| 18:12:30 | dom96 | haha |
| 18:12:35 | EXetoC | interesting |
| 18:15:29 | Sergio965 | Does anyone virtualize Linux on OS X in here? |
| 18:15:36 | Sergio965 | I'm having a lot of issues with VMWare's Unity. |
| 18:15:46 | Sergio965 | (And wondering if there's a better alternative_ |
| 18:15:47 | Sergio965 | ) |
| 18:16:03 | fowl | Only a couple os xers in here |
| 18:16:51 | bmp | I virtualize Linux on OS X with Parallels as my main dev environment. |
| 18:16:54 | bmp | Have had no issues. |
| 18:17:21 | bmp | One of the fun things that comes from being a Machead who works on a Windows/Linux hybrid product. :-/ |
| 18:17:35 | Sergio965 | Yeah, I can imagine. |
| 18:17:57 | Sergio965 | I use OS X for almost all of my development work. But when it comes to OS development, GNU's toolchain simply works much, much better on Linux. |
| 18:19:13 | Sergio965 | Perhaps I'll try Parallels. |
| 18:19:36 | Sergio965 | I tried it once. But Parallels loads up all of these Kexts at boot and I didn't like that. |
| 18:26:49 | Sergio965 | I'll give it a shot. |
| 18:28:54 | gradha | you might want to try virtualbox since you are at it |
| 18:29:59 | Sergio965 | Yeah, I've heard good things about Virtualbox. Does it have a Unity/Ubiquity like feature? |
| 18:30:29 | gradha | no idea, I don't like oses spilling onto other ones anyway |
| 18:30:53 | Sergio965 | I do too, but it takes up too much screen real estate. |
| 18:34:29 | * | q66 quit (Ping timeout: 240 seconds) |
| 18:37:42 | Araq | "Hey there, would you like to enable our new repository design?" |
| 18:37:48 | * | shafire joined #nimrod |
| 18:37:51 | shafire | hi |
| 18:37:57 | dom96 | hello shafire |
| 18:37:57 | Araq | I dunno ... would I like that? |
| 18:38:01 | Araq | hi shafire |
| 18:38:11 | shafire | how are you? |
| 18:38:15 | gradha | Araq: of course you would, are you from the past? |
| 18:38:21 | dom96 | Araq: They will force it on you eventually anyway. |
| 18:38:24 | Araq | chances are slim they improved anything |
| 18:38:41 | Araq | is it more osx like now? |
| 18:38:57 | gradha | they have a nice sidebar which takes out width for the whole height of the page forcing you to have a bigger window/screen |
| 18:39:01 | shafire | any plans to feature contracts? |
| 18:39:05 | Araq | did they finally find a way to implement a broken task bar in a webapp? |
| 18:39:29 | dom96 | Araq: Are the platform names documented anywhere? |
| 18:39:43 | Araq | I think system.nim lists the valid cpus and oses, dom96 |
| 18:40:20 | gradha | shafire: can you ellaborate on contracts? is it just like public preconditions instead of internal asserts at the beginning of a proc? |
| 18:40:45 | Araq | shafire: I've been working on making the compiler prove simple properties of the code, the feature may be advanced to provide pre- and postconditions |
| 18:40:56 | dom96 | Araq: argh, sometimes it's annoying that this stuff is all over the place. |
| 18:41:10 | Araq | however they work at compiletime |
| 18:41:27 | Araq | and if the compiler can't prove it correct, you have to write it in a style so that it can |
| 18:43:34 | shafire | I thought something like Ada 2012 provides "Preconditions and postconditions define the expectations and obligations of a subprogram. Type invariants specify boundary constraints for objects of an encapsulated (private) type. Subtype predicates capture general constraints on data objects." |
| 18:45:15 | * | gradha wonders if it would be feasible to force such expectations not only at boundaries |
| 18:45:50 | Araq | afaik Ada simply provides some sugar for assertions and you still have to use Spark to prove things |
| 18:47:15 | Araq | pre- and postconditions don't have to be put in comments anymore but that's all there is to it |
| 18:50:28 | Araq | gradha: it is feasible but not very interesting |
| 18:54:40 | dom96 | Araq: I think we need dedicated docs for this somewhere. This is very useful when writing platform-dependent code. system.nim does not mention the fact that you can use defined(unix) for example. |
| 18:55:26 | Araq | but I don't like the 'defined' feature for that ... |
| 18:55:33 | dom96 | And it's nice to be reassured about what 'unix' actually includes. |
| 18:55:46 | Araq | when defined(unx) # typo remains uncaught |
| 18:56:09 | dom96 | what's the alternative? |
| 18:56:15 | Araq | unfortunately hostOs has the same problem ... |
| 18:56:32 | Araq | the alternative is to introduce an OS enum |
| 18:57:06 | * | q66 joined #nimrod |
| 18:57:08 | Araq | when hostOS == osLinux ... |
| 18:57:23 | shafire | I like it, that I can use subtypes |
| 18:57:35 | dom96 | ok then. But that's a whole other issue. |
| 18:57:56 | Araq | const osUnix = {osLinux, osMacosX, ...} |
| 18:58:02 | Araq | when hostOs in osUnix |
| 18:58:52 | Araq | but alright lets document it somewhere |
| 19:01:14 | Araq | the "compare branch" feature is new right? I love it :D |
| 19:01:49 | dom96 | it's not |
| 19:02:07 | dom96 | The new interface just gives you easier access to it. |
| 19:02:11 | Araq | oh ... |
| 19:02:17 | fowl | Sergio965: what are unity features? Virtualbox has nothing to do with a gui or desktop environment.. |
| 19:02:27 | shafire | Where can I find Nimrod example code? |
| 19:02:42 | shafire | sry found it |
| 19:03:00 | fowl | Github/fowlmout |
| 19:03:01 | fowl | H |
| 19:03:04 | fowl | ;) |
| 19:05:09 | Sergio965 | fowl: Unity basically takes the Window manager of the guest OS and makes it look like the host's Window manager. So windows in your guest OS are windows in your host OS. |
| 19:05:24 | Sergio965 | Turns it Virtualbox has it and is called "Seamless mode". |
| 19:05:35 | EXetoC | plenty in the official distribution as well |
| 19:05:44 | EXetoC | shafire |
| 19:07:07 | EXetoC | maybe that's what you found |
| 19:07:33 | fowl | Sergio965: seamless in vbox means it doesn't capture ur mouse |
| 19:07:43 | shafire | EXetoC: yeah, you're right |
| 19:07:44 | fowl | Also vbox guest additions, check them out |
| 19:08:08 | EXetoC | and some real world code on github. just install everything using babel :> |
| 19:08:09 | Sergio965 | No. |
| 19:08:16 | Sergio965 | Guest additions allow that. |
| 19:08:18 | Sergio965 | Seamless mode is what I said. |
| 19:08:25 | Sergio965 | http://www.makeuseof.com/tag/virtualboxs-seamless-mode-combine-operating-systems-desktop/ |
| 19:09:15 | fowl | Pretty sure seamless isn't going to make windows guest os look like your ubuntu desktop |
| 19:09:40 | Sergio965 | Did you check out the article? |
| 19:10:17 | fowl | No I'm not at a computer and dnt really care anyways |
| 19:10:28 | Sergio965 | Alright... |
| 19:10:31 | fowl | To be blunt |
| 19:10:34 | fowl | Sry |
| 19:10:45 | gradha | Sergio965: fowl uses telepathy to communicate on irc |
| 19:10:48 | Sergio965 | I was just pointing out what it was. It seemed like you were simply trying to contradict whatever it was I said. |
| 19:11:01 | Sergio965 | (Even after I provided proof.) |
| 19:12:22 | shafire | I found out about Nimrode at this blog article: http://sebastiansylvan.com/2013/05/25/language-design-deal-breakers/ <- He don't like Nimrod because of null-pointer exceptions |
| 19:12:28 | shafire | -e |
| 19:12:33 | shafire | Nimrod, sry |
| 19:12:54 | Sergio965 | Ah yeah, I rea that article as well. |
| 19:12:55 | fowl | Sergio965: sry not my intention |
| 19:12:56 | Sergio965 | read* |
| 19:13:02 | Sergio965 | Hacker News? How'd you come across it? |
| 19:13:09 | Sergio965 | (Although that's not how I found out about Nimrod) |
| 19:13:14 | dom96 | A blog article mentioning Nimrod, how the hell did I miss this? |
| 19:13:29 | Araq | latest github version checks for "not nil" pointers ... |
| 19:13:48 | fowl | shafire: there no null exception, u get segfault with a backtrace |
| 19:14:05 | dom96 | oh, it's quite old, and mentions Nimrod at the bottom. Meh. |
| 19:14:23 | fowl | Null exception implies checking is done on every access which would be l4me |
| 19:15:07 | Araq | fowl: you can transform the segfault into an exception which is what the JVM does |
| 19:15:33 | Araq | it doesn't require any overhead unless your offsets start getting to large |
| 19:16:30 | dom96 | why aren't we doing this then? |
| 19:16:34 | Araq | it's just that I didn't bother to do that as catching a NPE is braindead anyway, so you can't |
| 19:17:11 | Sergio965 | ls |
| 19:17:15 | Sergio965 | Fuck. This is not my shell. |
| 19:17:20 | dom96 | hrm, good point. People would start catching the exception instead of properly fixing their silly NPE bugs. |
| 19:17:57 | Sergio965 | Parallels Coherence is not as good as VMWare's Unity. In fact, I don't think it works... |
| 19:18:57 | gradha | don't know what the deal is with null pointer when we still haven't figured out a way for processes to cooperatively share memory and request/free them at runtime properly, meaning each works isolated and the OS requires virtual memory |
| 19:19:42 | gradha | there's just so many great problems waiting to be solved for the end user and we still focus on null pointers |
| 19:20:55 | gradha | I'm sure js on browsers will fix this |
| 19:21:05 | Araq | as I said, the null pointer problem is already solved with the latest version |
| 19:21:26 | Araq | it even is less annoying than Rust's solution afaict |
| 19:21:39 | fowl | What's that |
| 19:21:55 | Araq | Rust uses a sum type for "nullable" |
| 19:22:19 | Araq | Nimrod uses a static analysis that's based on the control flow |
| 19:22:36 | shafire | Araq: Can I read about this somewhere? |
| 19:22:51 | Araq | shafire: I haven't documented it yet, sorry |
| 19:25:01 | fowl | What of calling c functions that may or may not initialize a ptr |
| 19:25:09 | fowl | How could u know or disable it |
| 19:25:43 | Araq | fowl: ptr T stays as it is, 'ptr T not nil' is enforced at compile time |
| 19:26:38 | Araq | so yeah you need to add "not nil" and that's an impertinence and it's the wrong default to start with, bla bla, bla ... |
| 19:27:52 | fowl | Btw in fowlgrammar its goingto be "pointy T ain't nothin" just for the lulz |
| 19:28:02 | Araq | it doesn't solve anything in the compiler itself btw; it would force me to write: if isNil(n.typ): InternalError(n.info, "type is nil") everywhere |
| 19:28:41 | Araq | that's a tiny bit nicer for the users of the compiler at the expense of my productivity |
| 19:29:11 | dom96 | hrm, existsFile returns false when given a path to a symlink |
| 19:29:40 | * | dom96 wonders how he's suppose to check that it exists |
| 19:30:06 | gradha | a symlink is not a file, you have to dereference it, like a pointer, since it can point to a missing file |
| 19:30:22 | gradha | or it could point to a directory |
| 19:30:44 | dom96 | yeah, that makes sense. |
| 19:30:51 | gradha | but yeah, usually you have a proc which is "raw" and nother which "follows symlinks" for user convenience |
| 19:31:30 | dom96 | no wait. |
| 19:31:35 | dom96 | I'm wrong, it does return true. |
| 19:31:56 | EXetoC | Araq: I guess you can just make it a function |
| 19:32:10 | dom96 | But only if the file it points to exists. |
| 19:32:36 | EXetoC | if you're going to check for that several times anyway |
| 19:32:52 | gradha | dom96: it seems the os module is short on symlink features, only through walkDirRec you would be able to detect them |
| 19:33:05 | dom96 | indeed |
| 19:33:19 | Araq | EXetoC: it's not for "several times". It's EVERYWHERE and it needlessly implements a check that the hardware does for free |
| 19:33:35 | dom96 | perhaps I should just add some symlink functions to the os module? |
| 19:34:14 | gradha | dom96: typically you would have a "stat" like proc which returns information on a path, like type, permissions, dates, etc |
| 19:34:39 | Araq | dom96: yeah but there is also walkDirRec which claims to support pcLinkToFile, pcLinkToDir but doesn't |
| 19:35:25 | gradha | another advantage of the stat-like proc is you get all the info at once, otherwise calls to getFileSize or getLastModificationTime each incur a IO trip |
| 19:35:34 | Araq | er make that 'walkDir' on windows |
| 19:35:42 | Araq | for posix it is supported |
| 19:36:46 | dom96 | I suppose a general stats proc would be nice. |
| 19:36:52 | dom96 | Araq: Thoughts? |
| 19:37:15 | Araq | meh, I don't like it but go ahead |
| 19:37:16 | gradha | dom96: that would be nice, and usually highly platform specific |
| 19:37:48 | shafire | mh, I can't find it, are regex case statements allowed? |
| 19:38:03 | shafire | like in scala? |
| 19:38:05 | dom96 | but maybe we should also provide a existsSymlink for consistency? |
| 19:38:07 | Araq | shafire: no, but you can write a macro that supports it |
| 19:38:17 | shafire | ok |
| 19:39:05 | gradha | dom96: the existsWhatever procs are usually a wrapper around the stat like proc for convenience, and usually nobody bothers for symlinks because they are platform specific |
| 19:39:38 | gradha | dom96: how does a symlink look to windows mounting an ext2 partition? a file? |
| 19:39:57 | dom96 | no idea |
| 19:39:57 | EXetoC | shafire: http://nimrod-code.org/manual.html#statement-macros_toc that's a start :> |
| 19:41:06 | fowl | gradha: u can't mount ext2 without some proprietary drivers iirc |
| 19:41:28 | Araq | dom96: I suggest you implement it for babel first and then extract it and put it into os.nim later |
| 19:41:34 | fowl | So who knows, prob diff each driver |
| 19:41:49 | dom96 | Araq: good idea |
| 19:42:40 | fowl | dom96: windows vista+ also has symlinks |
| 19:42:58 | gradha | dom96: yeah, macosx stupid resource forks FTW! |
| 19:43:00 | shafire | EXetoC: thanks |
| 19:43:22 | dom96 | gradha: what? |
| 19:43:37 | Sergio965 | Yo. |
| 19:43:40 | Sergio965 | OS X is da bomb. |
| 19:43:50 | shafire | with homebrew, yeah |
| 19:43:58 | gradha | dom96: older macosx have resource forks, which are just something nobody wants to touch |
| 19:44:27 | gradha | https://en.wikipedia.org/wiki/Resource_fork |
| 19:44:40 | dom96 | I see. |
| 19:45:01 | gradha | people like to think of macosx as unix, try to use rsync to backup (a version without resource fork support) and fail to restore |
| 19:45:35 | Araq | or try to use 'fork' with Cocoa, gradha |
| 19:45:48 | Araq | that was an issue you encountered, right? |
| 19:46:03 | gradha | Araq: it's another kind of fork |
| 19:46:12 | Araq | yeah I know |
| 19:46:35 | gradha | the Cocoa fork issue reminded me of MFC dll hell, with single threaded and multithreaded versions |
| 19:46:50 | EXetoC | regular forks are fine |
| 19:46:51 | gradha | ah, good times, VC6 crashing on input, long compile times... |
| 19:47:00 | EXetoC | actually, I prefer spoons. spoons are underrated imo |
| 19:47:22 | Araq | spoons are unprofessional |
| 19:47:29 | Araq | you can barely hurt anybody with them |
| 19:47:53 | Sergio965 | gradha: Mac OS X is BSD. |
| 19:48:22 | fowl | Was some kind of bsd..what happened to it? |
| 19:48:28 | EXetoC | c(:) |
| 19:48:40 | Sergio965 | OS X is based on the Mach kernel developed at CMU. |
| 19:48:44 | dom96 | Spooning is *the* best way to code: https://bitbucket.org/spooning/ |
| 19:48:45 | Sergio965 | What was based on BSD. |
| 19:48:50 | Sergio965 | Which* |
| 19:48:58 | fowl | O ok |
| 19:49:05 | Araq | an old version of BSD; you can simply go through the list of BSD's security fixes to see how to attack Mac OS X ... |
| 19:49:18 | EXetoC | shafire: I wonder if any of the regular expression functions work at compile-time though. if not then good luck :> |
| 19:49:28 | Sergio965 | I doubt most of those attacks work anymore. |
| 19:49:36 | gradha | macosx is starting to be too mainstream, I'm going to virtualbox myself into hurd for maximum hipster points and port nimrod to it |
| 19:49:37 | EXetoC | no wait, it doesn't even have to run then. duh |
| 19:49:43 | Sergio965 | The OS X architecture has deviated substantially from BSD since then. |
| 19:49:59 | Araq | I wouldn't wonder at all if they still worked |
| 19:50:00 | EXetoC | so that won't exactly be rocket science I guess |
| 19:51:17 | dom96 | gradha: I shall be using RISC OS on my RPI. |
| 19:51:38 | fowl | Sounds riscy |
| 19:51:53 | fowl | Sea wut aye deed thurr |
| 19:52:08 | Araq | EXetoC: they don't work at compile time but it doesn't matter the macro can simply transform into an 'if' |
| 19:52:33 | dom96 | fowl: ermahgerd thets soo funneh |
| 19:52:59 | fowl | Hrr hrr hrr |
| 19:53:30 | EXetoC | jejejejejeje |
| 19:53:46 | Araq | stop it. |
| 19:54:25 | Araq | many people read the logs and we're not #funzone :P |
| 19:54:39 | gradha | what logs? |
| 19:54:44 | EXetoC | :> |
| 19:54:58 | gradha | the NSA is filtering them anyway |
| 19:55:02 | fowl | Is that a real chan I'm gonna check it out |
| 19:55:13 | dom96 | Araq: Liar, there is no such thing as #funzone :( |
| 19:55:33 | Sergio965 | Hooray for the NSA! Keeping us all safe at the expense of privacy. :D |
| 19:56:12 | shafire | thanks for the information guys |
| 19:56:21 | gradha | dom96: so what happened with NimBot, did you interrogate it? |
| 19:56:24 | fowl | We'd be just as safe if we all agreed to stop using words like terrorism |
| 19:56:34 | gradha | dom96: it has not been behaving very well lately |
| 19:57:06 | dom96 | gradha: I did. But it has used its right to remain silent. |
| 19:57:34 | gradha | try to put him in conflict with the second law of robotics |
| 19:57:56 | gradha | hmm... or maybe not, we wouldn't get logs at all then! |
| 19:58:58 | dom96 | NimBot don't care about no robotics laws. |
| 20:00:02 | fowl | Who wantsto start working on some projects like games or something, anyting we can monetize |
| 20:00:18 | dom96 | omg why is the remainder app on my iPad so crap |
| 20:00:38 | fowl | I'm poor |
| 20:00:42 | gradha | dom96: haha, the reminder app on ios is the most crap software I've seen, crashes every time I use it |
| 20:00:44 | dom96 | It keeps reminding me, even though I told it that I've already done that thing! |
| 20:01:07 | dom96 | seriously. I tick it, and it stays there! |
| 20:01:10 | gradha | fowl: I have many ideas, but I suck on the monetizing front |
| 20:01:35 | dom96 | haha, I turned off the alarm remainder and the text turned to "(null)" |
| 20:01:36 | dom96 | nice |
| 20:01:37 | fowl | I'm a fan of the shareware model |
| 20:01:40 | fowl | Or nagware |
| 20:01:58 | dom96 | fowl: I'm always down. |
| 20:02:05 | shafire | I am looking forward to see 1.0, going to bed now. bye! |
| 20:02:08 | dom96 | I have too many open source projects... |
| 20:02:19 | fowl | Night shafire |
| 20:02:27 | dom96 | shafire: good night, thanks for stopping by! |
| 20:04:06 | gradha | fowl: one of my ideas is taking http://www.tursiops.cc/drops, rewriting it in nimrod, create tutorials on it to run on desktop, mobile and js, then give it for free away |
| 20:04:15 | gradha | as you can see, not much monetization there |
| 20:05:10 | * | shafire quit (Quit: Page closed) |
| 20:05:11 | dom96 | The most successful indie games are always ones which allow you to be creative, i.e. Minecraft and Kerbal Space Program IMO |
| 20:06:11 | Araq | just build a half decent RTS, I would buy it ;-) |
| 20:06:32 | EXetoC | yeah. no macro-management plz |
| 20:06:35 | gradha | I enjoy the creativity of torture and death I exert in xcom or masters of orion |
| 20:06:49 | EXetoC | I mean pls. srsly, who came up with "plz"? |
| 20:06:53 | Araq | dunno what happened ... there used to be lots of them ... now there is only Starcraft 2 |
| 20:07:10 | gradha | Araq: what? I'm backing one right now |
| 20:07:21 | gradha | it's called... I can't remember |
| 20:07:23 | dom96 | Age of Empires 2 HD! |
| 20:07:36 | dom96 | There is also a pretty good open source RTS: 0 A.D. |
| 20:07:57 | gradha | Araq: there you go http://www.kickstarter.com/projects/659943965/planetary-annihilation-a-next-generation-rts |
| 20:08:11 | dom96 | I was considering rewriting Frets on Fire in Nimrod. |
| 20:08:18 | dom96 | But it looks like a lot of work. |
| 20:08:38 | Araq | gradha: meh ... already know it, looks boring |
| 20:08:38 | dom96 | gradha: Doesn't that cost like 70 dollars? |
| 20:09:00 | dom96 | I recall people complaining on steam that it's so expensive for an alpha |
| 20:09:13 | gradha | dom96: it's still not out yet, so no idea |
| 20:09:35 | gradha | dom96: oh, you have to pledge a lot to get to the internal alpha builds, but who wants to play an alpha version anyway? |
| 20:10:17 | dom96 | I bought Minecraft and KSP at alpha :P |
| 20:10:51 | fowl | dom96: u should register a channel, make it private for us and gradha so we can start brainstormimg cuz I'm serious about this I need $ lol |
| 20:11:12 | fowl | Or we could use #fancyfeast I own that channel |
| 20:11:15 | EXetoC | won't range support floats? |
| 20:11:17 | gradha | fowl: and I'm serious about being bad on the money part |
| 20:11:45 | fowl | That's OK gradha well figure it out |
| 20:11:55 | fowl | We'll |
| 20:12:01 | Araq | EXetoC: yes. I never tested that feature though tbh |
| 20:12:04 | gradha | fowl: in fact, I'm sort of the unoriginal person easily swayed towards grandiose projects, if you make the decissions I could follow |
| 20:12:05 | * | dom96 joined #fancyfeast |
| 20:13:18 | EXetoC | Araq: it said something about ordinal types IIRC. I'll try again directly with some float type rather than "type RT = float64" |
| 20:14:47 | * | fowl quit (Changing host) |
| 20:14:47 | * | fowl joined #nimrod |
| 20:20:53 | Sergio965 | Virtualbox is brilliant. |
| 20:21:08 | gradha | as in it glows? |
| 20:21:16 | Sergio965 | Yes. |
| 20:22:41 | Sergio965 | Like fire. |
| 20:23:11 | gradha | maybe keep those folders away to avoid catching any of that |
| 20:25:05 | Sergio965 | But it's contained! That's what virtualization is all about. :) |
| 20:25:24 | Sergio965 | I'm quite impressed by VirtualBox. |
| 20:25:52 | gradha | hmm... how can a virtual machine impress? |
| 20:26:01 | Araq | my vitualbox doesn't support seamless mode ... :-( |
| 20:26:10 | Sergio965 | I'm impressed by how well Seamless mode works. |
| 20:26:37 | Sergio965 | Considering Parallel's doesn't support it's similar feature, Crystal mode, on Linux guests. |
| 20:28:52 | dom96 | Araq: I think it's a Mac OS X only thing? |
| 20:29:11 | Sergio965 | I don't think it is. |
| 20:29:21 | EXetoC | meow |
| 20:29:28 | Sergio965 | moo |
| 20:29:49 | gradha | animal farm, now on ebook |
| 20:33:01 | EXetoC | just tell us when the logs are working properly again :> |
| 20:33:49 | Araq | The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which. |
| 20:33:53 | Sergio965 | Okay, I'm not so impressed anymore. It's quite slow. |
| 20:34:15 | Araq | EXetoC: they work for me |
| 20:34:44 | dom96 | it took quite a while to fix actually |
| 20:34:49 | EXetoC | ok let's be serious from now on then. gotta make a good impression |
| 20:45:29 | dom96 | But it's so quiet when we are serious :( |
| 20:45:49 | Araq | bbl |
| 20:46:10 | gradha | maybe we should introduce EXetoC to the amazing work of kpop with nimrod? |
| 20:46:11 | EXetoC | Araq: it seems to fail only when I define a new type that has some range |
| 20:46:26 | EXetoC | and that's another thing I shuold write a test case for :> |
| 20:46:30 | fowl | EXetoC, there is an infinite range of numbers between 0.0 and 1.0 |
| 20:46:47 | EXetoC | yes, but it's still a range |
| 20:46:59 | EXetoC | and it worked with a var just now |
| 20:46:59 | dom96 | gradha: Yes, in fact it's mandatory! |
| 20:47:05 | Araq | fowl: that doesn't mean you can't have sugar for a >= 0.0 and a <= 1.0 |
| 20:47:13 | EXetoC | and then I tried to give it a value outside the range and the compiler complained |
| 20:47:13 | Araq | it means it's no ordinal type though |
| 20:47:25 | fowl | ah ok |
| 20:47:28 | EXetoC | yeah |
| 20:47:53 | gradha | EXetoC: I started implementing https://github.com/gradha/genieos which is an awesome nimrod module |
| 20:48:14 | gradha | it's awesome not because it does something awesome, but because the docs are filled with references to a kpop group |
| 20:48:34 | EXetoC | how many seconds fewer will I have left if I eat this sugary ice cream? |
| 20:48:39 | EXetoC | gradha: saw that before. awesome |
| 20:49:04 | EXetoC | it doesn't take long before you've seen most open source Nimrod projects out there :> |
| 20:49:13 | gradha | true |
| 20:49:27 | fowl | we are hipsters |
| 20:49:42 | Araq | bmp: http://nimrod-code.org/manual.html#procedures explains briefly it's possible for a "command statement" |
| 20:50:21 | Araq | so it only works for statements |
| 20:50:37 | Sergio965 | Now I want ice cream. |
| 20:54:27 | NimBot | nimrod-code/babel master b562620 Dominik Picheta [+0 ±3 -0]: Implements binary package symlinking to $babelDir/bin.... 3 more lines |
| 20:54:27 | NimBot | nimrod-code/babel master 266ef67 Dominik Picheta [+0 ±1 -0]: Merge branch 'master' of github.com:nimrod-code/babel... 3 more lines |
| 20:54:53 | dom96 | gradha: Could you test babel on Mac OS X please? |
| 20:56:26 | EXetoC | just make sure there's no rootkit code in there! |
| 20:56:29 | EXetoC | it might be a trap |
| 21:01:02 | dom96 | yes, NimBot is hiding in there. |
| 21:09:21 | reactormonk | do we have a somewhat fast XML lib? |
| 21:09:55 | dom96 | xmltree |
| 21:10:00 | reactormonk | preferably SAX |
| 21:10:06 | reactormonk | the files are ~ 200MB each |
| 21:10:22 | EXetoC | uh oh, method bug |
| 21:11:02 | dom96 | reactormonk: I would trust Araq's brilliant XML parser engineering. |
| 21:11:27 | reactormonk | dom96, let's put it to the test |
| 21:11:39 | dom96 | EXetoC: hehe, I've been using Nimrod for a long time now, and I still have not used methods anywhere. |
| 21:14:26 | gradha | dom96: what's the stuff you need testing with babel? |
| 21:14:45 | dom96 | binary packages |
| 21:14:49 | dom96 | the symlinking |
| 21:15:12 | dom96 | just create some dummy binary package and check if it can be ran when you add ~/.babel/bin to your PATH |
| 21:15:24 | EXetoC | ok |
| 21:20:09 | EXetoC | nested method |
| 21:20:18 | reactormonk | dom96, that's not a parser, but a generator |
| 21:20:24 | EXetoC | oops |
| 21:20:54 | dom96 | reactormonk: oh sorry, there is a xmlparser module too |
| 21:20:55 | EXetoC | hitting the right key on tiny keyboards is hard |
| 21:21:02 | EXetoC | nested method calls is the problem |
| 21:21:58 | gradha | oh, I'm connected to moorcock.freenode.net |
| 21:23:18 | reactormonk | could anyone check if longhorn.tacc.utexas.edu resolves for you? |
| 21:24:02 | gradha | ping: cannot resolve longhorn.tacc.utexas.edu: Unknown host |
| 21:24:39 | reactormonk | damnit |
| 21:24:43 | gradha | PING utexas.edu (128.83.40.147), anything else fails |
| 21:29:40 | * | Sergio965 quit (Ping timeout: 276 seconds) |
| 21:33:43 | * | Sergio965 joined #nimrod |
| 21:49:09 | * | Trix[a]r_za is now known as Trixar_za |
| 22:22:27 | gradha | dom96: wasn't babel meant to work if a local babel file is present? can't get it to run |
| 22:22:47 | dom96 | how are you trying to run it? |
| 22:23:03 | gradha | this is the file http://pastebin.com/X84pFUPS named genieos-trash |
| 22:23:14 | gradha | I try "babel install genieos-trash" |
| 22:23:33 | dom96 | that's the problem, run "babel install" instead. |
| 22:23:44 | gradha | Invalid field: bin |
| 22:23:47 | gradha | needs a section? |
| 22:24:01 | gradha | ah, wait, forgot to install, maybe |
| 22:26:57 | gradha | it works fine, but the babel install should log to stdout the linkage, it doesn't at the moment |
| 22:27:47 | gradha | the output of the install command was http://pastebin.com/y0SsVexy |
| 22:28:41 | dom96 | ok, will add that. |
| 22:29:29 | gradha | it correctly overwrites the link on the next babel install command |
| 22:30:41 | gradha | so I updated the version number and renamed the binary, it is installed, but the previous one is not erased |
| 22:31:20 | gradha | keeping track of them would be a pain, but maybe the installation could simply check the validity of symlinks and remove those which are dead |
| 22:31:48 | gradha | though maybe that doesn't work so well, as the previous version would still remain |
| 22:31:57 | dom96 | Do you mean you renamed the binary which the symlink points to and the symlink wasn't deleted when you tried to reinstall the package? |
| 22:32:29 | gradha | what I did was change the package number, rename trash.nim to newtrash.nim and change the name of the bin setting |
| 22:32:47 | gradha | then I installed and it created a new directory, of course the previous one was not removed, so both exist now |
| 22:33:02 | gradha | there's no babel uninstall |
| 22:33:22 | dom96 | indeed, a 'babel remove' would be able to remove it properly. |
| 22:33:32 | dom96 | Since the .babel file specifies the bin name. |
| 22:33:45 | dom96 | But I think the user can manage to remove it for now :P |
| 22:35:37 | NimBot | nimrod-code/babel master 468e11e Dominik Picheta [+0 ±1 -0]: Information about what symlinks are created is now printed to stdout. |
| 22:36:50 | dom96 | gradha: Can you test to make sure the binary can find its AppDir properly and by extension can read the files it depends on? |
| 22:36:56 | * | OrionPK joined #nimrod |
| 22:37:03 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:39:23 | gradha | dom96: I would need a binary which has dependant files for that |
| 22:40:03 | dom96 | import os; echo readFile(getAppDir() / "blah.txt") |
| 22:40:19 | dom96 | create a "blah.txt" file in your packages dir |
| 22:40:25 | dom96 | it will get automatically installed |
| 22:41:29 | Araq | EXetoC: nested methods shouldn't be allowed by the compiler |
| 22:41:29 | OrionPK | hey dom96 did you see my message last night about babel |
| 22:43:21 | dom96 | OrionPK: just read it. setCurrentDir sounds like a great idea. |
| 22:43:35 | OrionPK | cool |
| 22:44:19 | EXetoC | Araq: I'm not sure why, but ok. I'll just add another method |
| 22:44:51 | gradha | dom96: http://pastebin.com/LpWrrhhJ |
| 22:45:28 | dom96 | I don't think babel relies on its current working dir much, except for 'babel install'. But maybe I should switch the cwd back once the command runs, just to play safe. |
| 22:45:29 | EXetoC | maybe this will force my code to be less crap, who knows :> |
| 22:45:45 | OrionPK | yeah |
| 22:45:50 | OrionPK | thats what I was expermenting with |
| 22:45:58 | OrionPK | setCurrentDir before and after to restore it |
| 22:46:04 | OrionPK | wasnt sure if it was necessary |
| 22:46:56 | gradha | dom96: shouldn't you add a getBabelAppDir() and people use that? |
| 22:46:59 | dom96 | OrionPK: The only reason I simply used 'cd' in the command I was executing is because I wasn't actually aware of setCurrentDir. |
| 22:47:11 | dom96 | gradha: argh |
| 22:47:16 | OrionPK | ah, i wasnt either ;) |
| 22:47:23 | dom96 | Why must Mac OS X be difficult. |
| 22:47:25 | OrionPK | I went through the os module to find it |
| 22:47:38 | dom96 | OrionPK: thank you :) |
| 22:47:41 | gradha | rather than difficult, it's doing what you are telling it to do |
| 22:48:27 | dom96 | it works the way I want it to on Linux :\ |
| 22:48:31 | Araq | that's bad, add something like this to the docs: "In the shell this command is commonly spelt as `cd`:idx:." |
| 22:48:59 | Araq | whenever you don't find something in the index, the index should be improved |
| 22:49:03 | dom96 | Araq: I think a better idea is to say that in the docs of execCmd |
| 22:49:35 | dom96 | "You can use setCurrentDir to specify the working directory for the execution using this proc" |
| 22:49:42 | Araq | execCmd lists common shell commands and that you don't need them? ok |
| 22:49:49 | gradha | dom96: maybe nimrod under linux has magic to resolve the symlink of getAppDir which macosx lacks? |
| 22:50:07 | fowl | |
| 22:50:07 | fowl | |
| 22:50:08 | fowl | test |
| 22:50:11 | fowl | omg what |
| 22:50:18 | gradha | yes |
| 22:50:20 | OrionPK | thanks for that fowl |
| 22:50:21 | * | dom96 readies the ban hammer |
| 22:50:23 | fowl | sorry |
| 22:50:25 | Araq | nope, linux is simply smarter than macosx when it comes to /proc |
| 22:50:26 | OrionPK | ;D |
| 22:50:34 | fowl | i saw my cursor was on the right and wanted to see what the hell was happening |
| 22:50:41 | fowl | guess i had a ton of spaces there.. |
| 22:50:53 | gradha | Araq: I expected the getAppDir would just read the first argument of the process |
| 22:51:17 | Araq | that's the generic fallback |
| 22:51:29 | Araq | it got special code for lots of OSes |
| 22:51:33 | OrionPK | that's a convention, but not required, no |
| 22:53:11 | dom96 | The Mac OS X implementation of getAppFilename looks rather desperate. |
| 22:53:14 | gradha | maybe http://stackoverflow.com/questions/799679/programatically-retrieving-the-absolute-path-of-an-os-x-command-line-app/1024933#1024933 |
| 22:53:49 | gradha | huh, they changed the shade of green used for ticks on stackoverflow |
| 22:55:02 | gradha | the more generic answer that got me there was http://stackoverflow.com/a/1024937/172690 |
| 22:56:21 | dom96 | gradha: Could you try it out? |
| 22:56:39 | gradha | it seems to be using that |
| 22:56:56 | gradha | it calls getExecPath1 which is a wrapper around _NSGetExecutablePath |
| 22:57:09 | gradha | what is missing is the realpath to resolve symbolic links |
| 22:57:22 | dom96 | It doesn't use realpath which the answer mentions though |
| 22:57:41 | gradha | "The path may contain symbolic links, "..", etc. but the realpath function can be used to clean those up if needed. See man 3 dyld for more information." |
| 22:57:56 | gradha | maybe there's a problem adding that? |
| 23:00:21 | dom96 | what makes you think that? |
| 23:00:25 | gradha | well, expandFilename already does call realpath, with a hack for macosx 10.5 too |
| 23:00:36 | gradha | so it would be a matter of adding expandFilename at the end on result |
| 23:01:34 | dom96 | ok, add it then |
| 23:01:56 | Araq | supporting macosx is more work than supporting windows ... yet one of these 2 claims to be posix compatible. interesting, hmm? |
| 23:02:00 | gradha | now it works |
| 23:02:54 | Araq | gradha: maybe we need to add that for the BSDs too |
| 23:02:55 | dom96 | Might be worth mentioning in the docs for getAppFilename/dir that it expands symlinks. |
| 23:03:11 | dom96 | yo apotheon |
| 23:03:21 | dom96 | Any luck with that freebsd machine? |
| 23:04:01 | apotheon | sorry |
| 23:04:08 | apotheon | Things are *really* busy this month. |
| 23:04:10 | gradha | the code I've used is http://pastebin.com/873FDMfH if you want it |
| 23:04:14 | apotheon | Much more so than I expected. |
| 23:04:21 | apotheon | . . . so no, no luck yet. |
| 23:04:25 | dom96 | apotheon: No worries. Just a friendly reminder. |
| 23:04:38 | apotheon | Thanks. Keep up the reminders -- they'll shame me into getting things done eventually. |
| 23:05:03 | fowl | if you want a bsd to test on put pc-bsd in a VM |
| 23:05:18 | dom96 | fowl: I want a BSD for nimbuild. |
| 23:05:32 | fowl | ah |
| 23:06:22 | gradha | I can actually see the value in getAppDir returning the path vs the realpath, especially if you want to print it to the user in a help dump of arguments on the command line, like "use /path/to/bin -switches" |
| 23:06:41 | gradha | the symlinked version might surprise the user |
| 23:07:11 | gradha | but maybe there the program should just query the first param and avoid getAppDir? |
| 23:08:10 | dom96 | I don't know. I think getAppDir should be consistent on all platforms, and it just so happens that the real path is more useful I would say. |
| 23:08:36 | gradha | it will be worth mentioning that in the docs too, to avoid surprises |
| 23:09:30 | dom96 | Mention what? |
| 23:09:48 | gradha | the usage of realpath to resolve symlinks |
| 23:10:10 | dom96 | Isn't saying that symlinks are resolved enough? |
| 23:10:35 | gradha | yes |
| 23:10:53 | dom96 | Also I presume you don't want to create a pull request, so I will commit it myself. |
| 23:15:58 | NimBot | Araq/Nimrod master dfbb7b3 Dominik Picheta [+0 ±1 -0]: Symlinks are now expanded in os.getAppFilename on Mac OS X. |
| 23:23:16 | NimBot | nimrod-code/packages master 6016300 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds hyperlinks FTW. |
| 23:23:16 | NimBot | nimrod-code/packages master 8394965 Dominik Picheta [+0 ±1 -0]: Merge pull request #16 from gradha/pr_hyperlinks... 2 more lines |
| 23:28:04 | * | DAddYE_ joined #nimrod |
| 23:31:35 | * | DAddYE quit (Ping timeout: 255 seconds) |
| 23:45:09 | * | DAddYE_ quit (Remote host closed the connection) |
| 23:45:42 | * | DAddYE joined #nimrod |
| 23:47:32 | * | DAddYE_ joined #nimrod |
| 23:48:12 | * | DAddYE quit (Read error: Connection reset by peer) |