| 00:00:14 | vbtt | EXetoC:indentation sensitivity is far more acceptable today than case/underscore insensitivity. |
| 00:00:45 | vbtt | Python got a lot of hate initially but after using it people realized it's actually quite desirable. |
| 00:01:06 | EXetoC | vbtt: sure |
| 00:01:20 | sale4one | people are afraid of new things :) |
| 00:01:44 | vbtt | or things that look like old things (cobol) they didn't like |
| 00:01:55 | Matthias247 | vbtt: I love the multiple ways to call functions ;) |
| 00:03:23 | sale4one | thats beacuse they realised that new is good and everything else has become obsolete |
| 00:03:37 | vbtt | Matthias247:good for you :) |
| 00:03:42 | Matthias247 | still undecided about whitespace and case insensitivity. Must try it more for myself |
| 00:04:02 | vbtt | is there any real word program written in rust today, btw? (except the compiler) |
| 00:04:10 | vbtt | i know go has quite a few. |
| 00:04:19 | sale4one | nice |
| 00:04:23 | vbtt | a really good sign is nimrod has so many non trivial ones. |
| 00:04:25 | EXetoC | I know there are a couple of official project |
| 00:04:25 | sale4one | what about gui apps in go :D |
| 00:04:30 | EXetoC | s |
| 00:04:39 | EXetoC | servo for example |
| 00:04:51 | Matthias247 | they are doing a browser in rust. That's the official project |
| 00:04:59 | Matthias247 | besides the compiler |
| 00:05:11 | * | zahary quit (Quit: Leaving.) |
| 00:05:12 | vbtt | Matthias247:indentation based blocks work very well. |
| 00:05:59 | vbtt | Matthias247:it's very rare anyone using python complains about it. otoh, many people praise it. |
| 00:06:02 | Matthias247 | it looks nice for sure. Only a little worried about accidental errors. E.g. due to misbehaving editors. Will see how it works |
| 00:06:23 | vbtt | Matthias247: why is it any worse than using {}? |
| 00:06:37 | vbtt | or if you have a misbehaving editor, you have bigger problems :) |
| 00:07:31 | vbtt | at least you'll get a syntax error for non aligned code - you'll have to perfectly align it to another level in some situations to make it valid code. and it'll be easy to spot. |
| 00:07:36 | Matthias247 | now an addiontal whitespace is more easily inserted and a single unclosed { can easily be detected |
| 00:08:27 | Matthias247 | that's what I thought. And accidently inserted tabs should also be discovered by the compiler I think |
| 00:08:53 | renesac | most of the time, yes |
| 00:08:55 | vbtt | Matthias247: if the code can be parsed, the compiler wouldn't know it was an accident. |
| 00:09:04 | vbtt | most of the time the code wouldn't make sense. |
| 00:09:26 | EXetoC | you could disallow mixing. seems reasonable |
| 00:09:28 | renesac | and it is more easy to see wrong identation than a if block with two statments but no {}, for example |
| 00:09:41 | vbtt | anyway, i'll let you make your mind on it. |
| 00:09:50 | Matthias247 | it says tabulators not allowed :) |
| 00:09:50 | Araq | actually python is worse than nimrod 'cause it allows for tabs |
| 00:09:57 | vbtt | right |
| 00:10:01 | EXetoC | oh |
| 00:10:12 | vbtt | python realized the mistake too late. |
| 00:10:16 | renesac | Araq, in python 3 mixing tabs and spaces is a instant error |
| 00:10:20 | renesac | yeah |
| 00:10:27 | Araq | renesac: really? cool |
| 00:10:53 | vbtt | yes they mostly fixed the tabs-spaces issues. ideally they would just disallow tabs but some ppl want them i guess. |
| 00:10:54 | sale4one | could they just add something to convert them ? |
| 00:11:10 | sale4one | it should be simple enough |
| 00:11:14 | vbtt | sale4one:of course, there are scripts. |
| 00:11:17 | Varriount|Mobile | And if you absolutely want tabs, you can always use a source code filter |
| 00:11:27 | * | carum joined #nimrod |
| 00:11:32 | Matthias247 | sale4one: the question is into how many spaces to convert them :) |
| 00:11:33 | sale4one | so really thats not even a problem |
| 00:11:49 | Matthias247 | and that depends on the editor settings of the person who has written the code |
| 00:11:54 | vbtt | Matthias247:that's the issue with mixing tabs and spaces |
| 00:12:02 | EXetoC | you could apply some heuristics |
| 00:12:07 | vbtt | which is a flaw in python 2.x but not nimrod |
| 00:12:42 | vbtt | in python, the meaning is fixed - 1 tab = 8 spaces i think (or 4) |
| 00:12:51 | sale4one | I think just tabs should be used, that way anyone can set the things how they want |
| 00:13:05 | sale4one | 4 |
| 00:13:09 | vbtt | sale4one:the problem is aligning continuation lines. |
| 00:13:32 | vbtt | you want to align them to something in the above line. |
| 00:13:43 | vbtt | so you're forced to write some spaces there. |
| 00:14:12 | vbtt | and then they wont line up for someone with a different editor. |
| 00:14:22 | vbtt | anyway, g2g. |
| 00:14:29 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:15:02 | EXetoC | I'm not a fan of vertical alignment |
| 00:15:17 | sale4one | there needs to be some order |
| 00:15:32 | sale4one | as I said, Go is the best one when it comes to that |
| 00:16:03 | Matthias247 | the best for what? |
| 00:16:38 | sale4one | coding standards, indetations and all that |
| 00:17:02 | sale4one | you can write code as you like |
| 00:17:10 | sale4one | but still you deliver it uniform |
| 00:17:22 | Matthias247 | hmm, there are good coding standards for most languages. And if you have a good IDE it can even auto-enforce it |
| 00:17:49 | sale4one | but go comes with a formater which you must use |
| 00:18:04 | Matthias247 | visual studio let's you only write C# code in the way Microsoft likes :-) |
| 00:18:52 | sale4one | That's why I like Go, you have just one standard, not the internal standards of every company/organisation |
| 00:19:39 | sale4one | I would really like to see everyone use PEAR standards with php, but still every major framework use its own |
| 00:21:04 | dom96 | Does Go refuse to compile your code unless you use the formatter? |
| 00:21:14 | Araq | dom96: no |
| 00:21:22 | sale4one | but it reformats it |
| 00:21:26 | dom96 | Well then you don't have to use the formatter. |
| 00:21:54 | Araq | dom96: that's right but when you don't the Go-Nazis come over and punch you in the face |
| 00:22:02 | * | darkf joined #nimrod |
| 00:22:14 | dom96 | hah |
| 00:22:15 | Matthias247 | I still have no clue for what to use Go - so I'm ok with it :) |
| 00:22:43 | dom96 | Is their hobby going through Go github projects and forcing people to use the formatter? |
| 00:22:50 | sale4one | compiler shows warnings on things like misspositioned { . .. . |
| 00:22:54 | Araq | why this is not seen as the fascism that it is, is beyond me |
| 00:23:40 | Varriount|Mobile | Wait, do they really go through GitHub projects? |
| 00:23:41 | sale4one | its not, as I said you still write code as you like, its just its being formated later |
| 00:23:52 | EXetoC | [closed] gofmt, biatch! |
| 00:24:21 | Araq | sale4one: that's like saying "you can still say everything as long as nobody can hear you" |
| 00:24:47 | Araq | in other words, fascism :P |
| 00:25:24 | renesac | http://www.secnetix.de/~olli/Python/block_indentation.hawk <-- this is a good myth busting about python identation |
| 00:25:27 | EXetoC | but then, can you prove that you did indeed say something? |
| 00:25:43 | renesac | someone should link in that embebed forum talk about nimrod |
| 00:25:44 | sale4one | look at the standards as laws, you have them in democratic countries :D |
| 00:25:56 | Araq | and it's only tolerated when it comes to "coding standards" really |
| 00:26:00 | dom96 | I don't get to vote on them though :P |
| 00:26:26 | Araq | just imagine people telling you how you should put things on your desk |
| 00:26:35 | dom96 | The funny thing is that if we were to force a specific style people would go apeshit. |
| 00:26:46 | Araq | or telling you you should wear the company's uniforms |
| 00:26:50 | dom96 | And yet everyone wants a common style. |
| 00:27:21 | renesac | of course, everyone must use my prefered style |
| 00:27:36 | Araq | "no, do not put the pencil here! it has to be *above* the paper! Dude!" |
| 00:28:24 | renesac | I don't like nimrod standard of two spaces identation (I prefer 4), but I try to follow it |
| 00:29:08 | Matthias247 | Araq: but your pencil is only used by you. But your code is probably read by hundrets of other guys |
| 00:29:24 | renesac | and aporia should really have visible lines for each indentation |
| 00:29:33 | sale4one | this will go to the infinity :D we all have out opinions :) but of the topic , thanks for welcoming me here :) I will be back for sure and now I need to sleep :D bye and thanks again |
| 00:29:48 | Araq | sale4one: good night |
| 00:29:51 | renesac | it helps a lot in deep nested code (not that such code should be encouraged, but sometimes is needed) |
| 00:29:52 | * | sale4one quit (Read error: Connection reset by peer) |
| 00:30:16 | Matthias247 | I think it's good to have a consistent code style inside libraries. But what it exactly looks like is not that important |
| 00:30:37 | Araq | Matthias247: that's a common falicy imho |
| 00:31:11 | Araq | *fallacy |
| 00:31:37 | Matthias247 | just had to look up that word :) |
| 00:32:01 | Araq | when you have 70K lines of code, that amounts to a book of perhaps 2000 pages |
| 00:32:21 | Araq | nobody reads it |
| 00:32:37 | Araq | you can skim though and get the larger picture of it |
| 00:33:10 | Araq | code isn't nearly as often read as people think it is |
| 00:34:44 | Araq | and when you really *read* it, you have to read slowly and carefully because it's *code* |
| 00:35:30 | renesac | a consistent style and naming helps to read faster to get a larger picture of it |
| 00:35:46 | Araq | renesac: only to some extend |
| 00:35:46 | Matthias247 | yes. But in this cases it will be still easier to understand if it's somewhat consistent |
| 00:35:51 | renesac | and at least regarding naming, nimrod compiler/std lib cares |
| 00:35:58 | renesac | and sytle too, of course |
| 00:36:09 | renesac | as it is easier |
| 00:36:29 | Araq | in reality you don't even notice small violations of some "standard" |
| 00:36:45 | Araq | the human brain is very weak at this |
| 00:37:20 | Matthias247 | but probably it's even more problematic when different programming paradigmas and libraries clash together in large projects |
| 00:37:46 | dom96 | Araq: I disagree. |
| 00:38:06 | dom96 | Araq: You surely heard of grammar nazis. |
| 00:38:20 | Araq | dom96: well? |
| 00:38:53 | dom96 | It's very easy for the human brain to notice mistakes in people's grammar. |
| 00:39:20 | dom96 | i.e. violations of the English language, which is a standard. |
| 00:41:01 | Araq | dom96: I disagree. How can you explain the fact then that grammar constantly evolves? |
| 00:41:33 | * | vbtt joined #nimrod |
| 00:41:53 | vbtt | i rejoined to chime in :) |
| 00:42:12 | dom96 | Araq: Because people are too ignorant to stick to some "standard" or too lazy or both. |
| 00:43:09 | vbtt | grammar evolves but slowly. and people generally stick to an accepted convention even with various options. |
| 00:43:36 | dom96 | The reason grammar constantly evolves though is because people are not perfect, they make mistakes in their speech. |
| 00:43:39 | Araq | vbtt: if that would be true only K&R style would exist for C |
| 00:43:52 | Araq | but there are lots of different styles for C |
| 00:44:49 | Araq | and if that would be true, we wouldn't need coding standards at all, instead we *force* people to adhere to them, one way or the other |
| 00:45:06 | vbtt | yeah people prefer different styles. the real question is is it desirable to have everyone use the same style. |
| 00:45:16 | vbtt | go forces ppl, pretty much. |
| 00:45:28 | Araq | you need to *enforce* the consistency or else you don't get consistency |
| 00:45:50 | vbtt | i think what you're saying is it is not particularly useful to have a consistent style across different libraries or code bases (or even different parts of a file, perhaps?) |
| 00:46:47 | Araq | yes, consistency is incredibly overrated |
| 00:47:24 | vbtt | i'm not as strong as the go guys on this but I do think having the same style across various projects is desirable. and having one style within one project is extremely desirable. |
| 00:47:30 | Araq | and in the real world, it doesn't exist, you have to learn to live without it |
| 00:48:07 | Araq | vbtt: projects in the real world often use different libraries which use different conventions, or they use multiple programming languages |
| 00:48:24 | vbtt | yes of course. |
| 00:48:40 | Araq | or you have things like "I want to break the rule for this identifier name because it's mapped to this CSV entry" |
| 00:48:42 | vbtt | people *learn to live with it* implies that ideally you wouldn't have to 'live with it' |
| 00:49:30 | vbtt | so total consistency is impossible - thats true. but is maximizing it desirable? |
| 00:49:54 | Araq | well some flexibility in reading means I don't have to force my fellow to give up his preferred placement of {} |
| 00:50:00 | vbtt | Araq: If I wrote a very useful nimrod stdlib library but used snake_case - would you accept it as is? |
| 00:50:25 | Araq | I personally would |
| 00:50:31 | vbtt | ok |
| 00:50:49 | Araq | I wouldn't because others wouldn't like it |
| 00:51:17 | Araq | vbtt: flip this question |
| 00:51:41 | Araq | if you have some very useful code, do you refuse to use it because it's not written in your preferred style? |
| 00:51:50 | vbtt | very good question |
| 00:52:00 | vbtt | of course not - i will use it. |
| 00:52:11 | vbtt | and actually i may not complain much about it either, but other people will. |
| 00:53:08 | Araq | imho the tool should provide the consistency, tools are much better at it |
| 00:53:17 | vbtt | you mean like gofmt? |
| 00:53:22 | Araq | but this means the tool *renders* it the way I like |
| 00:53:29 | vbtt | oh you mean the editors. |
| 00:53:37 | Araq | not that I have to write/transform it to the common style |
| 00:53:38 | vbtt | same code - different views. |
| 00:54:23 | vbtt | perhaps someone should write a fuse filesystem for editing nimrod that can transform the style. |
| 00:54:29 | vbtt | that way every editor will work :) |
| 00:54:40 | Araq | nice idea |
| 00:55:26 | vbtt | while i'm not a style nazi, I'm not as strong an outlier as Araq. |
| 00:56:19 | vbtt | programmer specific style is perfectly valid point of view. it's just not the mainstream one. |
| 00:56:40 | vbtt | and so many people like go fmt because it lets them avoid style discussions. |
| 00:58:02 | vbtt | hmm, i think fuse filesystem will express nimrods philosophy very well. |
| 00:58:10 | vbtt | but then people need to check stuff into github :/ |
| 00:58:19 | vbtt | which style will it use? |
| 00:58:35 | vbtt | sadly, the problem is not easily fixed. |
| 00:58:52 | Araq | vbtt: yes and the problem got worse |
| 00:59:10 | Araq | apparently now people really read the code via github |
| 00:59:19 | Araq | that means in their browsers with no tool support |
| 00:59:31 | vbtt | well you could add tooling to the browser. |
| 00:59:41 | vbtt | browser plugin, git plugin, etc. |
| 01:00:00 | Araq | yeah but it's lots of work and so Go's worse is better approach really works better |
| 01:00:05 | vbtt | the phrase that comes to mind is.. |
| 01:00:08 | vbtt | lipstick on a pig. |
| 01:00:39 | vbtt | go is designed to fit in with the current mess. |
| 01:00:57 | Araq | a bit |
| 01:01:29 | vbtt | I mean - you can even include a github path directly in your source file. very convinient but bad idea imo. |
| 01:01:39 | Araq | go has its own unique problems imho when it comes to that |
| 01:03:18 | vbtt | yeah |
| 01:03:23 | vbtt | anyway, i g2g |
| 01:04:47 | vbtt | one last tidbit - the python stdlib was quite inconsistent because they accepted many useful libraries in different styles. however in 3.0 they've tried to make everything consistent. |
| 01:05:02 | vbtt | make whatever you want of that. |
| 01:05:09 | vbtt | bye guys |
| 01:05:20 | Araq | it's irrelevant because python distinguishes between these styles |
| 01:05:21 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 01:05:49 | Araq | make python itself style agnostic and it doesn't matter |
| 01:09:18 | dom96 | hrm, I may have to implement 'await' in the macro too |
| 01:09:24 | dom96 | I need to know whether the user wrote: |
| 01:09:29 | dom96 | await proc |
| 01:09:31 | dom96 | or |
| 01:09:35 | dom96 | var x = await proc |
| 01:09:46 | dom96 | argh |
| 01:10:08 | * | carum quit (Remote host closed the connection) |
| 01:10:13 | Araq | that looks easy enough to distinguish |
| 01:10:29 | dom96 | Would have to detect whether it's a proc or var also |
| 01:10:38 | dom96 | I can look for nnkCall I guess |
| 01:10:48 | dom96 | But yeah, definitely need to do it in the macro |
| 01:10:52 | dom96 | no way to do it with a template |
| 01:11:29 | Araq | sysio.nim(171) writeln |
| 01:11:30 | Araq | system.nim(1855) raiseEIO |
| 01:11:32 | Araq | Error: unhandled exception: cannot write string to file [EIO] |
| 01:11:35 | Araq | wtf? |
| 01:11:47 | Araq | how can writing to stdout fail like this? |
| 01:12:02 | dom96 | if stdout is redirected to a file perhaps |
| 01:14:58 | * | Matthias247 quit (Quit: Matthias247) |
| 01:21:48 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 01:24:52 | dom96 | Araq: Do we want the name 'await' btw? |
| 01:25:29 | Araq | yes |
| 01:28:16 | NimBot | Araq/Nimrod devel 07d2622 Araq [+0 ±1 -0]: actors.nim compiles again |
| 01:28:16 | NimBot | Araq/Nimrod devel 707ece8 Araq [+0 ±3 -0]: made 'koch web' work when current dir has a space in it |
| 01:43:26 | Varriount | Araq: Would you accept an additional feature to testament, a command line option specifying what the path/command needed to invoke the nimrod compiler? |
| 01:44:23 | Araq | Varriount: sure and that should even be easy to implement, the default command is some constant |
| 01:44:47 | Varriount | Currently koch tests uses the nimrod compiler found in the path, which is problematic for me, since I have 3 different nimrod installations on my system |
| 01:45:05 | Varriount | (32 and 64 bit nimbuild, and my own personal build) |
| 01:46:23 | Araq | Varriount: I already said "yes" :P |
| 01:47:14 | Varriount | Sorry, force of habit I've picked up from years of persuasive essay writing |
| 01:52:06 | Araq | dom96: a very encouraging article: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ |
| 01:52:28 | Araq | according to this guy, we do it exactly right |
| 01:53:51 | dom96 | I still haven't read enough about coroutines to decide whether we need them, but as far as asyncio is concerned they don't seem to be necessary |
| 02:04:01 | Araq | good night |
| 02:06:02 | dom96 | same here |
| 02:06:04 | dom96 | bye |
| 02:16:26 | * | nande left #nimrod (#nimrod) |
| 02:28:18 | * | nande joined #nimrod |
| 02:40:53 | * | carum joined #nimrod |
| 03:00:48 | * | dmac joined #nimrod |
| 03:01:36 | * | Demos joined #nimrod |
| 03:01:52 | Demos | did we get the GSoC application in? |
| 03:20:31 | * | dyu joined #nimrod |
| 03:25:30 | * | nande left #nimrod (#nimrod) |
| 03:29:53 | Varriount | Demos: Yep |
| 03:30:10 | Varriount | Demos: Now all we can do is hope. And code, of course |
| 03:31:10 | Varriount | Araq: If nimrod isn't to get proper coroutines, then iterators will have to make up for that lack (and must become more flexible) |
| 03:54:05 | * | brson quit (Quit: leaving) |
| 03:55:17 | * | athaudia1 quit (Ping timeout: 248 seconds) |
| 04:02:18 | Varriount | Demos: How has the VS integration been going? |
| 04:05:37 | * | athaudia1 joined #nimrod |
| 04:06:43 | * | zahary joined #nimrod |
| 04:08:20 | Varriount | Hi zahary |
| 04:08:25 | Varriount | Hi athaudia1 |
| 04:09:19 | Demos | good, idetools problems. codfe is on meh github |
| 04:11:06 | * | zahary quit (Ping timeout: 245 seconds) |
| 04:13:39 | * | DAddYE joined #nimrod |
| 04:18:05 | Demos | basicly I have building, projects, file addition and folder addition (and deletion) working. As well as syntax highlighting |
| 04:18:15 | Demos | completions do not work |
| 04:18:40 | Demos | I have not disabled tabulators, and debugging does not work |
| 04:19:01 | Demos | I also want additional syntax coloring based on idetools information |
| 04:19:16 | Demos | and I would /love/ not to have to save dirty buffers to use idetools |
| 04:19:28 | Demos | although atm having to spawn a new process for every request is the killer |
| 04:19:34 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 04:20:03 | Demos | I also hacked together a tool that will generate a .nimproj from a nimrod project, it really just recurses through all the children folders and adds .nim files there |
| 04:20:18 | Demos | and makes a build rule for the file you point it at |
| 04:20:58 | Demos | so pretty well, Varriount. If we get into GSoC I will probably end up applying to do the CAAS and tooling project |
| 05:25:49 | * | brson joined #nimrod |
| 05:25:49 | * | brson quit (Client Quit) |
| 05:31:06 | * | brson joined #nimrod |
| 05:40:14 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 06:11:07 | * | carum quit () |
| 06:45:42 | * | DAddYE quit (Remote host closed the connection) |
| 06:46:40 | * | skrylar joined #nimrod |
| 06:56:33 | skrylar | out of curiosity has threaded nimrtl support been improved since the 0.9.2 release |
| 06:56:46 | skrylar | last i read it wasn't tested very much |
| 07:00:46 | * | DAddYE joined #nimrod |
| 07:07:01 | * | dyu quit (Quit: Leaving) |
| 07:28:19 | Varriount | Hm. What should I work on now... |
| 07:33:34 | * | Varriount quit (Read error: Connection reset by peer) |
| 07:41:10 | * | aftersha_ joined #nimrod |
| 08:36:47 | * | dmac quit (Ping timeout: 246 seconds) |
| 08:47:46 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 08:52:00 | * | Demos quit (Read error: Connection reset by peer) |
| 09:07:33 | * | DAddYE quit (Remote host closed the connection) |
| 09:38:59 | * | aftersha_ joined #nimrod |
| 09:40:03 | * | awestroke joined #nimrod |
| 10:00:16 | * | zahary joined #nimrod |
| 10:01:55 | * | brson quit (Ping timeout: 260 seconds) |
| 10:11:15 | * | Matthias247 joined #nimrod |
| 10:24:04 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 10:32:19 | * | aftersha_ joined #nimrod |
| 10:35:54 | * | athaudia1 is now known as athaudia |
| 10:44:37 | * | sale4one joined #nimrod |
| 10:45:29 | sale4one | hi all :) |
| 10:49:16 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 10:58:15 | * | sale4one quit (Read error: Connection reset by peer) |
| 11:00:11 | * | awestroke quit (Remote host closed the connection) |
| 11:06:45 | * | aftersha_ joined #nimrod |
| 11:10:56 | dom96 | hi |
| 11:13:45 | * | skyfex quit (Ping timeout: 253 seconds) |
| 11:17:16 | * | aftersha_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 11:17:42 | * | aftersha_ joined #nimrod |
| 11:30:45 | * | skyfex joined #nimrod |
| 11:41:48 | Araq | skrylar: afaict nobody uses nimrtl so no, it hasn't been improved |
| 11:44:08 | * | io2 joined #nimrod |
| 11:46:24 | dom96 | Araq: Hey, figured out the cause of that bug I found last night |
| 11:46:28 | dom96 | and found another one already heh |
| 11:57:38 | dom96 | Araq: Also genSym is seriously broken. Please fix it. |
| 11:59:30 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 12:11:19 | Araq | dom96: I noticed |
| 12:13:03 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 12:13:08 | * | [1]Endy joined #nimrod |
| 12:13:40 | * | skyfex joined #nimrod |
| 12:13:53 | Araq | ping skyfex |
| 12:14:00 | skyfex | pong |
| 12:14:11 | Araq | are you up to fixing some compiler bugs now? |
| 12:15:02 | skyfex | Heh, maybe.. I've mostly been staring at the semantic checking surrounding instantiations of generics |
| 12:16:35 | skyfex | remember from the forums, I was interested in using values in generics |
| 12:17:10 | * | aftersha_ joined #nimrod |
| 12:18:10 | skyfex | but I think I'm starting to understand the compiler a bit |
| 12:22:33 | Araq | are you familiar with the tester? |
| 12:25:40 | skyfex | not yet.. I saw some "suite" things at the bottom of some module, is that related? |
| 12:25:55 | Araq | not really |
| 12:26:08 | Araq | well I'd like you to fix bug concerning exception handling |
| 12:26:28 | Araq | nimrod c tests/testament/tester |
| 12:26:46 | Araq | tests/testament/tester cat exception |
| 12:26:52 | Araq | tests/testament/tester --print html |
| 12:27:03 | Araq | should list a couple of tests, all green |
| 12:28:12 | Araq | then add new tests from the list of github issues |
| 12:28:44 | Araq | then take a look at ccgstmts.nim, "blockLeaveActions" and the related logic and fix things |
| 12:29:29 | Araq | but be warned, translating exceptions to C is mind-boggling |
| 12:29:42 | Araq | and much harder than I imagined |
| 12:30:30 | * | oal joined #nimrod |
| 12:31:23 | Araq | hi oal welcome |
| 12:31:31 | oal | Hi Araq :) |
| 12:32:11 | skyfex | I'd be glad to give it a shot, can't promise anything though ;) |
| 12:32:30 | Araq | well feel free to ask questions here |
| 12:33:08 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 12:37:02 | skyfex | Araq: any specific bug, or any related to exceptions? |
| 12:37:41 | skyfex | Things like this? https://github.com/Araq/Nimrod/issues/908 |
| 12:39:32 | Araq | skyfex: #391, #688 and #908 but the later might not be relevant |
| 12:40:02 | Matthias247 | I don't see an error in this issue. He closes the file before he writes to it? |
| 12:42:15 | Araq | skyfex: exception handling should be easier to fix then generic instantiation though ;-) maybe it's even a good start |
| 12:44:05 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 12:45:33 | * | skyfex joined #nimrod |
| 12:52:23 | * | sale4one joined #nimrod |
| 12:55:12 | skyfex | When I run ./koch temp, it seems to recompile al the modules, even if they haven't changed, is that necessary? |
| 12:59:41 | Araq | no, but --symbolFiles are broken and have been for quite some time now |
| 13:10:54 | EXetoC | Araq: ok so something simple as "import pegs" fails with the C++ backend, but not when -d:release is omitted |
| 13:11:03 | EXetoC | it complains about 'abs' in this case. any idea where to look? |
| 13:13:08 | Araq | I don't know |
| 13:14:21 | EXetoC | s/omitted/included |
| 13:15:23 | sale4one | Why do I get error message when I copy the example from tut2.html ? :/ |
| 13:16:40 | sale4one | first example* (says id is undeclared but it is declared) |
| 13:17:45 | Araq | sale4one: iirc it's a known bug with 0.9.2 |
| 13:17:54 | Araq | master or devel can handle it |
| 13:17:55 | Araq | bbl |
| 13:20:04 | sale4one | tell me, inhreriting from TObject doesn't count as a real inheritance? |
| 13:29:33 | * | aftersha_ joined #nimrod |
| 13:37:21 | * | [2]Endy joined #nimrod |
| 13:40:16 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 14:11:44 | * | darkf quit (Quit: Leaving) |
| 14:14:52 | NimBot | Araq/Nimrod newasync 8029a5d Araq [+0 ±3 -0]: more things case consistent |
| 14:14:52 | NimBot | Araq/Nimrod newasync 02662f5 Araq [+0 ±1 -0]: fixes #612 |
| 14:14:52 | NimBot | Araq/Nimrod newasync 3829faa Simon Hafner [+1 ±0 -1]: moved tsets test to collections/ |
| 14:14:52 | NimBot | Araq/Nimrod newasync 729d61a Araq [+0 ±1 -0]: edited compiler's config |
| 14:14:52 | NimBot | 14 more commits. |
| 14:16:45 | skyfex | Araq: Do you mind telling me a bit about how pushSafePoint, popSafePoint, currentexception, popCurrentException, etc? |
| 14:27:49 | EXetoC | Araq: stdlib.h is included in the Nimrod_system.c/cpp, so how are the other source files able to use symbols referenced in that header? abs for example. or does it come from somewhere else? |
| 14:28:10 | EXetoC | mAbsI: "(NI$2)abs($1)", |
| 14:30:40 | * | io2 quit () |
| 14:33:28 | skyfex | Araq: Hmm, think I'm starting to figure it out.. |
| 14:33:37 | skyfex | I'm commenting on https://github.com/Araq/Nimrod/issues/391 as i go aling |
| 14:33:39 | skyfex | *along |
| 14:33:54 | EXetoC | by not linking probably (gcc -c). I suppose it's a link order issue then |
| 14:34:14 | sale4one | is toUpper() a valid proc on a string ? |
| 14:34:59 | sale4one | *method or what is it |
| 14:36:29 | sale4one | Ok, I found out :) |
| 14:38:53 | EXetoC | or not. I give up |
| 14:47:48 | * | sale4one left #nimrod ("ERC Version 5.3 (IRC client for Emacs)") |
| 14:58:30 | * | noam joined #nimrod |
| 14:58:45 | * | BitPuffin joined #nimrod |
| 15:10:42 | * | PortableEXetoC joined #nimrod |
| 15:13:06 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 15:16:18 | * | aftersha_ joined #nimrod |
| 15:32:17 | * | PortableEXetoC2 joined #nimrod |
| 15:32:18 | * | PortableEXetoC quit (Read error: Connection reset by peer) |
| 15:35:12 | * | PortableEXetoC2 quit (Read error: Connection reset by peer) |
| 15:45:23 | * | sale4one joined #nimrod |
| 15:56:21 | * | ics joined #nimrod |
| 16:01:47 | Araq | EXetoC: you should replace (NI$2)abs($1) by (NI$2) ($1 >= 0? $1 : -$1) and rely on gcc's optimizer |
| 16:02:47 | Araq | or make it #include <math.h> and hope for the best ... |
| 16:05:00 | skyfex | Araq: Never mind my questions earlier.. I think I understand them now |
| 16:05:16 | skyfex | I know why issue 391 happens now.. just need to find out how to fix it |
| 16:05:24 | OrionPK | morning |
| 16:05:45 | OrionPK | what's new today? |
| 16:06:30 | * | ddl_smurf joined #nimrod |
| 16:07:06 | skyfex | But gotta go... fix it when i get back |
| 16:07:14 | Araq | skyfex: ok great |
| 16:16:36 | EXetoC | Araq: ok. I was just trying to figure out how the targets differ, but aren't those overloads in stdlib.h? |
| 16:17:01 | Araq | EXetoC: c imports 'abs' implicitly, most likely, c++ is stricter |
| 16:18:14 | EXetoC | Araq: I sure didn't expect that to be the case |
| 16:18:27 | EXetoC | I'll resume then |
| 16:27:21 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 16:27:48 | * | aftersha_ joined #nimrod |
| 16:30:24 | * | sale4one quit (Read error: Connection reset by peer) |
| 16:33:38 | * | sale4one joined #nimrod |
| 16:45:21 | * | foodoo joined #nimrod |
| 16:45:41 | foodoo | s |
| 16:46:59 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 16:49:12 | Araq | foodoo" |
| 16:49:14 | Araq | " |
| 16:49:17 | Araq | ! |
| 16:49:48 | foodoo | I unintentionally touched my mousepad. The letter s should have gone into another window |
| 16:50:33 | Araq | now the 's' belongs to us |
| 16:50:55 | foodoo | will it be the new channel mascot? |
| 16:51:17 | Araq | did I mention that people with too many 's' (== '$') need to donate? |
| 16:51:26 | foodoo | blood? |
| 16:52:04 | Araq | most people here live in countries where money is used to pay the bills ... |
| 16:52:32 | foodoo | ah, you mean bitcoins |
| 16:53:19 | * | Icefoz quit (Quit: leaving) |
| 17:09:39 | EXetoC | Araq: why is abs a special symbol? |
| 17:14:52 | BitPuffin | you mean a keyword? |
| 17:16:12 | * | foodoo quit (Quit: tiuq) |
| 17:16:22 | Araq | EXetoC: historical reasons I think |
| 17:22:01 | EXetoC | BitPuffin: no but the compiler provides the implementation |
| 17:22:18 | EXetoC | Araq: ok I might try to remove it then |
| 17:22:28 | Araq | EXetoC: ok, thanks |
| 17:28:17 | * | carum joined #nimrod |
| 17:39:27 | rixx | ha, can't donate $, don't have any |
| 17:48:24 | * | Demos joined #nimrod |
| 17:51:23 | * | sale4one quit (Ping timeout: 260 seconds) |
| 17:52:50 | EXetoC | Araq: I copied the one for floats. does it need to look like your string? basic tests are working |
| 17:59:38 | Araq | EXetoC: if the tests work that's good enough |
| 18:08:49 | dom96 | I am really starting to get used to working on Windows. |
| 18:10:48 | skrylar | dom96: uh oh |
| 18:17:47 | * | kudu joined #nimrod |
| 18:17:51 | * | kudu left #nimrod ("WeeChat 0.4.1") |
| 18:20:24 | * | carum quit (Remote host closed the connection) |
| 18:21:52 | EXetoC | Araq: there barely are any, but there's only so much you can test |
| 18:22:08 | * | skrylar is *seriously* considering Tcl bindings just for Tk |
| 18:23:19 | * | aftersha_ joined #nimrod |
| 18:27:26 | * | awestroke joined #nimrod |
| 18:29:52 | * | XAMPP joined #nimrod |
| 18:37:22 | * | Varriount joined #nimrod |
| 18:47:27 | Varriount | Araq: The PR for adding an explicit nimrod command/path option to the tester is up. |
| 18:48:15 | EXetoC | Araq: where should my test go? |
| 18:48:31 | NimBot | Araq/Nimrod devel 435cb1a Zahary Karadjov [+1 ±6 -0]: the delegator pragma becomes a set of dot operators |
| 18:48:31 | NimBot | Araq/Nimrod devel a495452 Zahary Karadjov [+0 ±2 -0]: handle nested case objects in destructor generation |
| 18:48:31 | NimBot | Araq/Nimrod devel 80f9ed2 Zahary Karadjov [+0 ±6 -0]: fix some regressions caused by tyTypeDesc[tyNone] |
| 18:48:31 | NimBot | Araq/Nimrod devel 26ff41a Zahary Karadjov [+3 ±27 -1]: Merge branch 'devel' of gh:/Araq/Nimrod into devel |
| 18:58:03 | * | awestroke quit (Remote host closed the connection) |
| 18:58:27 | skrylar | i wish nimrod would obey the CC environment variable instead of calling GCC always |
| 19:00:04 | EXetoC | Araq: nvm. stdlib I suppose |
| 19:02:35 | Varriount | skrylar: You can use a different compiler |
| 19:03:12 | skrylar | Varriount: i mostly just wanted to tell nimrod to use ccache |
| 19:03:18 | Varriount | ccache? |
| 19:04:01 | skrylar | ccache is a helper for gcc/clang |
| 19:04:23 | skrylar | it basically caches object files and if you ask it to compile the same .c, it will just put the .o back instead |
| 19:04:28 | skrylar | if and only if the output would be identical |
| 19:05:11 | skrylar | so for instance where nimrod keeps deciding the stdlib needs to be built, ccache would omit the need to compile those .c's repeatedly |
| 19:07:41 | Varriount | skrylar: iirc, nimrod's caching mechanism does work, to some extent |
| 19:09:10 | Varriount | For example, compiling the 'strutils' module 3 times, the first time, all three modules are compiler (strutils, parseutils, and system), the second, only two are compiled (strutils and parseutils), and the third, none are |
| 19:09:38 | Varriount | compiled, in that context, meaning that a c file is compiled into an object file |
| 19:10:42 | Varriount | skrylar: Would you consider a string a decent way to abstract away type differences between OS file ID's? |
| 19:11:23 | skrylar | well in my case when i compile my test program, it can end up re-building 3-6 system .c's for some reason or another |
| 19:11:36 | skrylar | right now that doesn't take a whole lot of time, but it seems needless |
| 19:11:52 | skrylar | Varriount: what do you mean by file IDs? |
| 19:12:01 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 19:12:09 | Varriount | skrylar: File system ID's, like the ones returned by stat |
| 19:12:34 | * | skyfex joined #nimrod |
| 19:12:34 | Varriount | Some OS's have 128 bit ID's, others have 64 bit, etc |
| 19:12:46 | skrylar | why wouldn't you use an opaque type at that point? |
| 19:12:52 | skrylar | its not like the user needs to touch it |
| 19:12:54 | * | micklat joined #nimrod |
| 19:13:21 | Varriount | Hm. They would probably only need to compare it. |
| 19:13:27 | skrylar | yep |
| 19:13:41 | skrylar | and opaque types like that are cheap thanks to templates |
| 19:13:59 | Varriount | skrylar: Huh? Howso? |
| 19:14:25 | skrylar | Varriount: when ThisOS: type blah_id = distinct(uint64)? |
| 19:14:48 | skrylar | now you have a uint for that platform that doesn't intermix |
| 19:14:52 | Varriount | Oh, that kind of machanism, not the 'template proc' kind of template |
| 19:15:05 | skrylar | yeah, just regular "template foo(...)" |
| 19:15:26 | skrylar | so it compiles to the same C as though you had written it like a special int to begin with |
| 19:15:37 | skrylar | I like that about nimrod |
| 19:16:26 | skrylar | I like how you can do really cheap-as-in-free wrappers in Nimrod for the most part |
| 19:17:00 | skrylar | all though testing for external C lib calls for errors is as sad as always |
| 19:19:37 | Varriount | skrylar: Hm> |
| 19:19:42 | Varriount | *? |
| 19:27:02 | skrylar | Varriount: well typing in "discard" every line is really annoying |
| 19:27:13 | micklat | {.discardable.} |
| 19:27:35 | micklat | besides, you shouldn't discard it |
| 19:27:44 | skrylar | what i usually do is just make the wrapper check the return code and throw nimrod errors |
| 19:28:41 | * | filwit joined #nimrod |
| 19:28:59 | * | surma joined #nimrod |
| 19:29:00 | micklat | is it possible to access a C array whose length is not statically known? |
| 19:29:27 | micklat | I know I can cast it to ptr array[0..999999,int] and index that, but it's kinda ugly |
| 19:30:13 | filwit | micklat: how else would you do such a thing? C arrays are just pointers. |
| 19:30:29 | filwit | hey all |
| 19:30:41 | micklat | I wish I could cast it to ptr array[0.., int], because the upper bound is just made-up |
| 19:30:54 | Varriount | Look! A wild filwit appeared! |
| 19:31:01 | micklat | or just deref ptr int, which I apparently can't |
| 19:31:11 | micklat | *index ptr int |
| 19:31:14 | Varriount | micklat: high(int)? |
| 19:31:17 | filwit | micklat: array[0..int.max, int] ? |
| 19:31:25 | micklat | ok, I guess, thanks |
| 19:31:27 | filwit | micklat: not sure 'int.max' is a thing. |
| 19:31:34 | filwit | but i'm sure something like it exists |
| 19:31:46 | Varriount | I think it's int.high |
| 19:31:59 | micklat | good, thanks |
| 19:32:49 | filwit | micklat: a better solution would probably be to use the length that your Nimrod code expects for the array instead of int.high though |
| 19:33:06 | micklat | that's a dynamic quantity |
| 19:33:12 | filwit | i see |
| 19:34:47 | skrylar | i'm not sure what you're going to gain by doing that though |
| 19:35:01 | skrylar | if you're setting the bounds to something crazy, a lot of the array APIs are going to act derpy |
| 19:35:43 | micklat | by doing what? |
| 19:35:54 | skrylar | by casting one of C's pointers to an array with INT_MAX length |
| 19:36:14 | micklat | what other choice have I got? I need to access elements 0..n-1, and n is not known at compile time |
| 19:36:46 | skrylar | access it like you would in C with pointer arithmetic? (unless nimrod doesn't let you do that, i haven't had to check yet) |
| 19:37:14 | filwit | micklat: you could cast to a raw pointer and use [] on it i think |
| 19:37:31 | micklat | you mean cast to ptr int? tried it, didn't work. |
| 19:37:48 | filwit | micklat: cast[ptr int](something)[index] ? |
| 19:37:58 | micklat | nope, does not work |
| 19:38:10 | micklat | but I can cast to int, do the arithmetic, then cast to ptr. |
| 19:38:14 | filwit | that doesn't make sense, somehow that should be possible |
| 19:38:31 | filwit | but i don't know the exact syntax off the top of my head |
| 19:38:32 | micklat | not sure that ptr arithmetic is an improvement though |
| 19:38:54 | micklat | so I think casting to ptr array[0..int.high, int] is best |
| 19:39:24 | filwit | well do what works i guess |
| 19:39:33 | filwit | they're basically the same thing anyways |
| 19:39:50 | skrylar | pointer arithmetic is what C is doing; making it an array is just going to confuse nimrod methods that ever try to use something like 'len' and will put in range checks that are worthless |
| 19:40:01 | skrylar | i guess you could surround that area in checks:off |
| 19:40:24 | filwit | Araq, dom96: congrats on submitting to GSoC. Have you found any students yet or gotten any feedback? |
| 19:40:37 | micklat | this is pretty common when working with C apis. I'm surprised there isn't some established practice. |
| 19:40:40 | skrylar | might be able to make it a distinct type and inherit [], that way trying to do stuff that won't work isn't considered valid for the type |
| 19:40:52 | dom96 | filwit: Demos and Varriount want to participate. |
| 19:40:57 | filwit | micklat: there's probably some common technique i'm unaware of |
| 19:41:12 | filwit | dom96: that's great! congrats guys. |
| 19:42:26 | micklat | Araq: do you agree that skrylar suggestion (distinct type, overriding [], ptr arithmetic) is the best solution? |
| 19:42:42 | filwit | dom96: btw, i was trying to install babel on Windows yesterday, but it wouldn't compile. Is Babel broken on Windows right now? Or should i report/fixit ? |
| 19:42:58 | filwit | dom96: i'm on Linux atm, so can't give you specific error |
| 19:43:13 | filwit | dom96: but it was a compiler error, and I was using devel |
| 19:43:59 | filwit | dom96: just wondering cause these days I have to spend more time on Windows and can't work on my project there cause OpenGL isn't part of Nimrod anymore |
| 19:44:36 | EXetoC | install manually? |
| 19:45:35 | filwit | EXetoC: that's the part that messes up, :P |
| 19:46:46 | filwit | i guess it's silly to ask about an error when i don't know the specifics |
| 19:47:12 | dom96 | Yes, just a bit :P |
| 19:47:23 | * | [1]Endy joined #nimrod |
| 19:48:13 | Araq | I have no time, just wanted to say I told you, dom96 |
| 19:48:33 | surma | So, in the documentation it says, that the tuple/object field operator `.` implicitly dereferences. Why is that not the case for the "method-syntax" (`someVar.function()`)? |
| 19:48:37 | Araq | package management doesnt work :P |
| 19:48:42 | dom96 | Araq: excuse me? |
| 19:48:58 | surma | Oh, it could be ambiguous, right? |
| 19:49:19 | Araq | surma: no, it simply an unimplemented feature |
| 19:49:27 | EXetoC | one dir for every test executable plz. so much git output :> |
| 19:49:39 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 19:49:46 | surma | Araq: Good to know :) |
| 19:50:05 | dom96 | Araq: That's not very nice man. |
| 19:50:13 | dom96 | And unfair for that matter. |
| 19:50:46 | filwit | i really like babel, for what it's worth |
| 19:51:21 | Araq | alright, i take it back then |
| 19:51:35 | * | [2]Endy joined #nimrod |
| 19:51:51 | dom96 | Araq: Don't piss on my work or you may find yourself without it ;) |
| 19:52:10 | surma | Another question I can't seem to answer for the manual: I have a variable `A` of type `T`, and a variable `B` of type `ref T`. How do I make `B` point to `A`? |
| 19:52:17 | surma | from the manual* |
| 19:52:29 | Araq | you cant |
| 19:53:49 | surma | Oh? I thought there were just like pointers just garbage collected. The first paragraph in the manual kinda sounds like that is possible. So, if I want to do that I need to use `ptr` and `.addr()`? |
| 19:53:56 | surma | BUt then I'm probably doing something wrong, eh? |
| 19:54:35 | Araq | yup |
| 19:54:44 | * | [1]Endy quit (Ping timeout: 246 seconds) |
| 20:07:05 | Varriount | Araq: Any suggestions on what I should work on now? (I got the nimrod-binpath feature for the tester done) |
| 20:07:15 | Araq | excuse me? |
| 20:07:26 | Araq | I told you to make a list of important failing tests |
| 20:07:37 | Varriount | Oh, right, I remember now. |
| 20:07:51 | Araq | or you could fix tests that fail because of nil->discard |
| 20:07:52 | Araq | brb |
| 20:09:17 | filwit | Araq: i'm trying to consume a module, by name, from within a macro. The consumed module doesn't need to be part of the resulting exe (i just need it's AST). What's the best option for doing this? I remember you mentioning importing some part of the compiler, but I forget which module/proc to use. |
| 20:10:48 | * | micklat quit (Remote host closed the connection) |
| 20:12:31 | filwit | Araq: i see macros.parseStmt() might work if I can read the file from within the macro. i'll try that first. |
| 20:16:11 | Demos | filwit, I got babel working on windows |
| 20:16:28 | filwit | Demos: did you run into any errors along the way? |
| 20:16:32 | Demos | you may need to use the master branch compiler or even 0.9.2 |
| 20:16:53 | filwit | Demos: okay. next time i'm on Windows i'll try that. Thanks for the tip. |
| 20:16:59 | Demos | the only issue I have is that only babel.bat is in the path, which is kinda wierd calling it from msys2's shell |
| 20:17:03 | Demos | but yeah, try that |
| 20:17:53 | dom96 | Compiles fine for me on devel. |
| 20:17:56 | EXetoC | Araq: it fails on snprintf too |
| 20:18:07 | filwit | dom96: what version of Windows? |
| 20:18:10 | dom96 | 7 |
| 20:18:16 | filwit | ah, i'm on 8.1 |
| 20:19:14 | EXetoC | Araq: I've conditionally added stdlib.h and stdio.h to nimbase.h and now nimrod can be compiled with cpp |
| 20:20:05 | filwit | parseStmt(readFile"testGen.nim") --> Error: cannot 'importc' variable at compile time |
| 20:20:06 | Demos | U an ib 8.1 as wekk |
| 20:20:19 | filwit | there's a compiler switch of something to allow file-reading at compile time? |
| 20:20:34 | filwit | Demos: wat? |
| 20:20:37 | EXetoC | Araq: anything wrong with that approach? |
| 20:20:58 | Demos | I am on 8.1 as well. Apperently my fingers migrated a bit there |
| 20:21:08 | filwit | lol, i see |
| 20:21:17 | filwit | I don't use Windows much except for work |
| 20:21:18 | EXetoC | filwit: gorge? |
| 20:21:21 | dom96 | filwit: Try slurp. However, does testGen contain importc? |
| 20:21:40 | EXetoC | I mean staticRead/slurp |
| 20:21:52 | filwit | dom96: no, it doesn't |
| 20:22:01 | filwit | and thanks for the 'slurp', will try |
| 20:22:12 | EXetoC | filwit: I thought he said that you cannot go that high up in the chain |
| 20:22:33 | filwit | EXetoC: not sure what you mean |
| 20:23:00 | filwit | nice, static read works |
| 20:23:09 | filwit | slurp is just an alias? |
| 20:23:14 | filwit | (why?) |
| 20:24:15 | filwit | (nevermind, don't care. just ocd about these things) |
| 20:24:23 | dom96 | because Araq likes the name |
| 20:26:13 | filwit | static read is much better, and 'slurp' shouldn't exist at all, IMO, but that's as much as i'm going to press that point. |
| 20:28:44 | filwit | on the plus side, it's awesome that Nimrod has this ability already built-in, so take my criticism with lots of salt |
| 20:30:08 | filwit | in fact, does D/C++ even have something equivalent? I can't think of anything off the top of my head |
| 20:30:30 | Demos | I like slurp. And D can execute almost anything at compile time, c++ can execute some stuff at compile time |
| 20:30:48 | Varriount | C++ Doesn't have anything like it, unless you can't all sorts of external templating systems (like *shudder* autotools |
| 20:30:51 | Demos | c++ can not do stuff like slurp though |
| 20:30:56 | Demos | Varriount, constexpr |
| 20:31:08 | Demos | and relaxed constexpr's in c++14 |
| 20:31:11 | Varriount | Demos: *unless you cound |
| 20:31:13 | Demos | but yeah, nothing like slurp |
| 20:31:40 | filwit | Demos: it's not about executing at compile-time, it's about parsing external files and turning them into AST without any external build-tools |
| 20:31:54 | filwit | (at compile time) |
| 20:32:08 | Demos | right, but constexpr and D's CTFE is as close as those languages come |
| 20:32:19 | filwit | i'm pretty sure on C# has something similar (probably Lisps of course) |
| 20:32:32 | Demos | well c# has reflection |
| 20:32:43 | Demos | but that is all runtime |
| 20:34:04 | filwit | true. though since C# is a VM, you can actually manipulate the AST with some of the new parse/AST utils and submit them for re-compile |
| 20:35:00 | filwit | not that i advocate that method over Nimrod's approach |
| 20:39:45 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 20:51:35 | * | sale4one joined #nimrod |
| 20:52:33 | filwit | 3 lines of code to parse a Nimrod file, convert it to AST, extract a type by name and run through it's children and each a copy of each one to another type... beautiful :D |
| 20:53:01 | dom96 | That's awesome. |
| 20:53:17 | filwit | yeah, meta-programming in Nimrod kinda puts other languages to shame, haha |
| 20:53:22 | dom96 | Wish it only took 3 lines to write the async stuff :P |
| 20:54:22 | filwit | well it only takes three lines cause of all the work you good folks do for me. and I'll probably need your async stuff in the not-so-distant future, so thanks for the effort |
| 20:55:11 | dom96 | Still pretty cool that I can do it all with macros though, no matter how much code it takes. |
| 20:55:36 | filwit | i'm not sure of what you've been doing with that, so I can't really comment |
| 20:56:13 | dom96 | Pretty much a clone of C#'s await. |
| 20:56:24 | filwit | i see, very cool |
| 20:56:38 | filwit | designed for pragmas ? |
| 20:57:01 | dom96 | yes |
| 20:57:12 | dom96 | proc foo(): PFuture[string] {.async.} = |
| 20:57:31 | dom96 | var line = await p.recv(sock) |
| 20:57:41 | dom96 | return line |
| 20:57:51 | dom96 | well, that's a silly example. But you get the idea. |
| 20:57:59 | filwit | yeah, looks nice :) |
| 21:01:41 | Varriount | Would someone mind explaining what C# 'await' is? |
| 21:01:44 | filwit | so {.compileTime.} works on vars too i see. I can expect that a compileTime seq wont bloat the exe? |
| 21:02:42 | Varriount | filwit: Depends on what you do with the sequence |
| 21:03:30 | filwit | but in general, the var itself won't bloat the code I assume. Guess i should just test. |
| 21:04:39 | filwit | Varriount: you should just read about async/await: http://msdn.microsoft.com/en-us/library/hh156528.aspx |
| 21:06:47 | Araq | filwit: compileTime seqs have all sorts of bugs |
| 21:06:53 | Araq | but code bloat is not among them |
| 21:07:38 | Araq | dom96: what it the most pressing bug? |
| 21:07:41 | filwit | Araq: okay. well if I run into anything i'll fix it. |
| 21:07:48 | filwit | Araq: or try to at least |
| 21:07:56 | dom96 | Araq: gensym |
| 21:08:07 | Araq | really? not the 'nil' bug? |
| 21:08:19 | dom96 | ehh, which one is that? |
| 21:08:31 | dom96 | I worked around them all. |
| 21:08:56 | Araq | ok ... |
| 21:14:14 | NimBot | Araq/Nimrod newasync 38a3c09 Dominik Picheta [+0 ±1 -0]: Async readLine now works. Fixes recv issues.... 6 more lines |
| 21:14:21 | Araq | ping zahary, zahary_ |
| 21:15:02 | skrylar | oh neat there are already nimrod bindings for tcl |
| 21:15:50 | zahary | pong Araq |
| 21:16:35 | dom96 | Araq: https://github.com/Araq/Nimrod/blob/newasync/lib/pure/asyncio2.nim#L622 You like? |
| 21:16:51 | dom96 | It's practically the same as the blocking implementation. |
| 21:18:29 | dom96 | Araq: Actually the 'void' bug may be more important. |
| 21:20:09 | zahary | dom96: if you remember, one of my gists showed how you can dual compile sync and async version of a proc from the same code |
| 21:21:14 | dom96 | Is that really useful though? I'd rather keep things simple. |
| 21:22:39 | zahary | it's not very useful in the sense that you should actively try to explore parallelism in the async version - e.g. place a few requests in parallel and wait for all of the results to be ready - the sync would be too crippled with such code |
| 21:23:34 | zahary | but you could drop the explicit Future return type and just use string (the async macro will implicitly make it a future) - that's one of the bits that's needed to keep the code the same |
| 21:25:32 | Araq | ah zahary you fix for #797 breaks manyloc/argument_parser |
| 21:25:32 | dom96 | I would rather keep it the way it is as it's clearer when you just want the PFuture. |
| 21:26:55 | zahary | the C# guys don't agree with you |
| 21:27:13 | dom96 | Hrm? Don't they do it the same way? |
| 21:27:23 | dom96 | except that it's s/PFuture/Task/ |
| 21:27:58 | zahary | I mean the do it as I suggest - the async proc is marked as returning "string", but that's converted to Task[string] under the hood and advanced users are exposed to it |
| 21:28:09 | zahary | * they do it * |
| 21:28:32 | zahary | Araq, I'll take a look |
| 21:28:45 | Araq | yeah and then you can end up with Task<Task<string>> |
| 21:28:54 | Araq | I agree with dom96, I think |
| 21:29:26 | dom96 | zahary: I'm confused. You suggest I just have 'string' instead of 'PFuture[string]' |
| 21:29:40 | dom96 | C# has 'Task<string>' in its async methods. |
| 21:29:49 | dom96 | Which is not what you suggest? |
| 21:29:57 | zahary | proc recvLine*(p: PDispatcher, socket: TSocketHandle): string {.async.} = |
| 21:30:20 | zahary | hmm, maybe I'm mistaken - let me checl |
| 21:32:32 | dom96 | Araq: Are we pursuing a deprecation path for sockets/asyncio? |
| 21:33:14 | Araq | dom96: of course; the new stuff is not stable at all, API-wise |
| 21:33:49 | dom96 | Araq: ok, should I keep the current naming scheme then? sockets2/asyncio2/net? |
| 21:34:01 | Araq | sure why not |
| 21:34:49 | zahary | hmm, indeed they use Task<T>; makes me wonder if it's just my memory that's failing or they have changed their plans since I watched the original async/await introduction plans |
| 21:36:24 | zahary | I personally prefer shorter code and see Future[T] {.async.} as a bit of tautology, but I don't have such a strong feelings about it |
| 21:36:29 | Varriount | dom96: Whats different between sockets2 and sockets? |
| 21:36:39 | * | carum joined #nimrod |
| 21:37:05 | dom96 | Varriount: We're splitting up sockets into a low-level 'sockets2' module and a high-level 'net' module. |
| 21:37:18 | Varriount | Ah, I see. |
| 21:37:28 | Varriount | That should probably be noted in the docs. |
| 21:46:33 | dom96 | Probably. |
| 21:46:43 | dom96 | ooh, async has its own category in the tester. |
| 21:50:19 | * | io2 joined #nimrod |
| 21:56:10 | Matthias247 | oh, async IO |
| 21:56:34 | Matthias247 | I started with that in rust, but eventually gave up |
| 21:56:34 | Varriount | Demos: Today I learned that Windows Explorer's Search box supports AND and OR operators |
| 21:56:40 | Matthias247 | maybe I should continue in nimrod :) |
| 21:59:18 | Demos | Varriount, I did not know that. are they 'and' and 'or' or like & and |? |
| 22:00:14 | Varriount | Demos: Well, 'OR' works, so I'm guessing AND does as well |
| 22:01:05 | Varriount | "type:nim foo OR bar OR baz" will get any files with foo, bar, or baz in their names, that have a type of '.nim' |
| 22:01:27 | * | tinAndi joined #nimrod |
| 22:01:42 | Demos | neat |
| 22:02:42 | Matthias247 | getting a good cross-platform API is however very hard |
| 22:03:01 | tinAndi | hi, i have a question before i even start using nimrod (just reading docs :)) is there a way to call a proc using it adress? |
| 22:03:11 | skrylar | Matthias247: sockets aren't that different really |
| 22:03:16 | Matthias247 | lol |
| 22:03:22 | skrylar | Winsock is a poor microsoftized clone of BSD Sockets afterall |
| 22:03:28 | Matthias247 | iocp vs epoll is fundamentally different |
| 22:03:35 | dom96 | yep, what Matthias247 said. |
| 22:03:42 | Matthias247 | if you stick to synchronous IO, yes, than it's equal |
| 22:03:50 | skrylar | oh you mean the select replacements |
| 22:03:56 | Araq | tinAndi: yes |
| 22:04:09 | skrylar | Matthias247: well Node.js uses a library that does something like that |
| 22:04:24 | Matthias247 | yes, libuv |
| 22:04:36 | Matthias247 | and for c++ there's also boost asio |
| 22:04:48 | Matthias247 | both have a quite different API |
| 22:05:06 | skrylar | i'm guessing what you'd want is to have a general class that you feed potential sockets in to, and then have different internal impls for platforms |
| 22:05:08 | Varriount | tinAndi: If you mean, does nimrod support passing procedures, yes it does. |
| 22:05:08 | Matthias247 | on uv you simply say: socket.beginReceive and you will get a callback each time data is received |
| 22:05:49 | tinAndi | i want to use it for setting up an eventhandler, for windows gui programming |
| 22:05:56 | Matthias247 | on asio you say socket.begin_read_some(buffer, size, callback) each time you want to receive something |
| 22:06:26 | Araq | tinAndi: that's entirely possible and not hard |
| 22:06:45 | Matthias247 | that's similar to dom96's code, but you provide the buffer |
| 22:07:16 | dom96 | hrm, it seems 'await' does not let you escape all callbacks. |
| 22:07:17 | Matthias247 | but preallocating the buffer ist wasteful on unix, where you only need it when select tells you so |
| 22:09:14 | tinAndi | thank you, so i go on and read more docs ;) on more, should i use the release version of nimrod or should i download the git repo to startup? |
| 22:09:41 | Matthias247 | dom96: Dart has a quite nice support for future based APIs which allows you to chain them without too much hassle and the need for async/await: https://www.dartlang.org/docs/tutorials/futures/#calling-multiple-funcs |
| 22:11:14 | filwit | tinAndi: I would probably download the git, so you can switch between devel (active development branch) and master (pretty much 0.9.2). Compiling is pretty straight forward. |
| 22:15:04 | * | brson joined #nimrod |
| 22:17:38 | filwit | tinAndi: ps, here's a little code example of Nimrod event procedures: https://gist.github.com/PhilipWitte/9025918 |
| 22:19:20 | * | zahary quit (Ping timeout: 252 seconds) |
| 22:19:54 | * | [2]Endy quit (Ping timeout: 260 seconds) |
| 22:21:19 | * | carum quit (Remote host closed the connection) |
| 22:22:03 | dom96 | Araq: Here is another crash you can fix: https://gist.github.com/dom96/039a0240dcc2625da7d7 |
| 22:22:08 | dom96 | Compile in newAsync branch |
| 22:24:10 | tinAndi | filwit : wow, this looks real easy and straight, thank you. |
| 22:24:21 | filwit | np :) |
| 22:29:46 | * | Amrykid quit (Changing host) |
| 22:29:46 | * | Amrykid joined #nimrod |
| 22:36:02 | skyfex | Is there a "5.times: ..." in nimrod? |
| 22:37:13 | filwit | not much need when you have: for i in 0..4: ... |
| 22:37:52 | filwit | but i'm not sure if there is such a template or not already in the standard libs |
| 22:38:21 | skyfex | not much need for "for i in 0..4: " when you have "var i = 0; while i <= 4: inc i" :P |
| 22:38:53 | Araq | *shrug* so add a 'times' template somewhere |
| 22:40:49 | skyfex | *glee* i know it's silly.. but i actually get happy when i can write what I'm thinking rather than to write things so the computer understands it |
| 22:40:59 | skyfex | Like the x.odd? in Ruby, rather than x%2==1 |
| 22:41:36 | Araq | yes, I always liked the idea of a rubylike.nim module that supports more ruby idioms |
| 22:42:25 | skyfex | any chance of enabling the use of ! and ? in proc,template and macro names? :P |
| 22:42:36 | Araq | no |
| 22:42:53 | Araq | not in my nimrod |
| 22:43:13 | Araq | they bite with user definable operators |
| 22:43:22 | skyfex | Fine! I'll make my own nimrod with ! and ? .. and blackjack .. and hookers! |
| 22:43:26 | filwit | use 'isOdd' instead, makes more sense anyways |
| 22:43:46 | tinAndi | event.nim(6, 0) Error: tabulators are not allowed??? is that true? |
| 22:43:53 | skyfex | heh |
| 22:44:04 | filwit | tinAndi: yes, you must use spaces |
| 22:44:11 | Araq | yes, use an editor that is not braindead |
| 22:44:47 | filwit | tinAndi: recommend Aporia: https://github.com/nimrod-code/Aporia |
| 22:45:11 | tinAndi | thank you :) i used my own editor ;) (okay, that's just an easy fix) |
| 22:47:11 | skyfex | filwit: Yeah, I can survive without ? in proc names. "isFoobar" is totally understandable. But the use of ! in methods in Ruby is actually kind of nice, it creates a nice ideom that reminds library writers to create one method that returns a modified copy of an object, and one that modifies the object directly |
| 22:47:39 | skyfex | Not that I'm gonna argue for it in Nimrod, just mentioning it :) |
| 22:47:56 | filwit | skyfex: i've never used Ruby, and don't know of the idiom you speak of |
| 22:48:02 | * | sale4one quit (Read error: No route to host) |
| 22:48:22 | tinAndi | btw the windows installer does not really works on win64bit (the folder is "Program Files (x86)") even on german systems ;) |
| 22:48:31 | skyfex | if x is an array then "a = x.sort", creates a sorted copy of x in a, while "x.sort!" sorts x in-place |
| 22:48:34 | filwit | skyfex: i just prefer 'isSomething' to 'something?' cause it's more consistent when you need to change 'is', eg, 'hasProp', 'wasSomething', etc |
| 22:48:45 | skyfex | filwit: sure, i'm with you there |
| 22:49:01 | Araq | skyfex: you're 5 years too late, everybody uses node.js now instead :P |
| 22:49:41 | * | sale4one joined #nimrod |
| 22:50:02 | skyfex | Oh, I'm one of those weird folks who use Ruby for other things than making web pages.. I've never even touched Ruby on Rails really ^_^ |
| 22:50:06 | filwit | tinAndi: I've installed on Win64 (win8). What problems are you having specifically? |
| 22:50:47 | Araq | he doesn't know it's "program files" even in german now, starting with vista iirc |
| 22:50:50 | filwit | skyfex: well Nimrod gives you quite a bit of expressive power, and should run significantly faster than Ruby :P |
| 22:51:44 | skyfex | filwit: Yeah, I can imagine using Nimrod for the same things.. Just need to write a replacement for Rake in Nimrod |
| 22:52:16 | Araq | hey, we already have, it's "nake" from fowl |
| 22:53:21 | filwit | skyfex: https://github.com/fowlmouth/nake |
| 22:53:25 | tinAndi | i solved them :) as i allready have gcc installed. So i have no probs anymore. but for 32bit progs it's "Program Files (x86)" and for 64bit progs it's "program files" even on german systems (win8.164bits) |
| 22:54:19 | skyfex | Ah, should have figured |
| 22:54:56 | Varriount | The windows installer probably needs it's default path changed to \Nimrod\ |
| 22:55:21 | filwit | ^ yeah, that's what D does |
| 22:55:23 | skyfex | that reminds me another small thing I miss from Ruby.. Symbols. But it's such a small thing. If I'd wanted a language with all my favorite features from other languages, I'd have made my own.. and it would probably suck |
| 22:55:39 | Varriount | And Gcc, and LLVM/Clang, And MSys |
| 22:56:14 | skrylar | skyfex: eh a symbol in ruby is just a string though |
| 22:56:21 | Araq | skyfex: type sym = distinct string; sym"foo bar" |
| 22:57:21 | Araq | there are rumors you can do: template `::`(x: expr): sym = astToStr(x) |
| 22:57:31 | Araq | ::myCoolSym |
| 22:57:33 | skyfex | skrylar: Well.. not precisely. There are some minor differences: http://www.robertsosinski.com/2009/01/11/the-difference-between-ruby-symbols-and-strings/ |
| 22:57:48 | skrylar | yeah i know; they're interned |
| 22:58:00 | Matthias247 | is there something like library-local-visiblity or friend declarations? In case you don't want to export a method to all but still want to use it outside of the module |
| 22:58:01 | filwit | Araq: soon... ::::::::::::::::::::::::MySuperSpecialSymbol |
| 22:58:05 | skyfex | ^_^ |
| 22:58:22 | EXetoC | Araq: so what exactly is implicitly "included" in C? because I had to add stdio.h in addition to stdlib.h |
| 22:58:29 | Araq | Matthias247: templates have friend like lookup rules in devel |
| 22:58:37 | EXetoC | (compile to C++) |
| 22:58:41 | Araq | EXetoC: don't do that |
| 22:58:59 | Araq | was hard to get rid of these |
| 22:59:10 | Araq | every #include in nimbase sucks for embedded targets |
| 22:59:41 | Matthias247 | Araq: is it only for templates and where can I find a description or example for it? |
| 23:00:11 | Araq | Matthias247: it's for generics too and I'm not sure it's documented |
| 23:00:38 | Araq | template foo*: expr = bar # bar not exported |
| 23:00:52 | Araq | from module import foo |
| 23:01:07 | Araq | foo # expands to bar and is allowed |
| 23:02:15 | EXetoC | Araq: ok but I don't understand this whole implicit thing, and why it's necessary for things like 'rand' as well when compiling to C++ |
| 23:02:55 | Araq | EXetoC: there is nothing implicit here, the symbols all have .header: "<stdio.h>" etc. |
| 23:10:15 | skyfex | Araq: When running "koch temp" it recompiles all modules even if they haven't changed.. is that necessary? |
| 23:10:36 | Araq | skyfex: again, for now it is because --symbolFiles are broken |
| 23:10:50 | skyfex | Oh, sorry, didn't see that you replied earlier |
| 23:10:57 | EXetoC | well yeah, but what about 'abs'? did you imply that it is implicitly included as per the standard? |
| 23:11:13 | Matthias247 | Araq: I think something for normal functions or types would also be helpful. But all in all I even like C#'s simple internal modifier even more than the friend thing, because it's quite convenient to use |
| 23:11:34 | Varriount | Araq: I've got nearly all of the nil depracation warnings fixed for the tests. |
| 23:11:44 | Araq | EXetoC: 'abs' is simply a bug not caught by the C codegen |
| 23:11:56 | Araq | Varriount: excellent |
| 23:12:29 | Trixar_za | If you turn around the b and throw in an i, it's something nobody wants to catch |
| 23:12:33 | Araq | Matthias247: not sure what you mean, but my bet is you don't know about 'export' yet |
| 23:13:05 | filwit | Matthias247: theoretically you can emulate 'internal' package behavior with 'include' |
| 23:13:14 | skyfex | Araq: Managed to fix issue 391, but introduced a regression in one of the other tests >_< |
| 23:13:53 | Araq | skyfex: now you know I told you in detail how we work here :P |
| 23:14:07 | Matthias247 | now I know that export is for rexporting names :) |
| 23:14:55 | filwit | Araq: is there 'friend-like' thing you mentioned earlier the 'bind' statement? |
| 23:14:58 | EXetoC | :E |
| 23:16:40 | Matthias247 | Araq: internal things can be seen used by everyone in the same compilation unit. That's more restricted than * in Nimrod which allows access to everyone but less restricted than without-*, which can only be seen from the current module |
| 23:17:58 | filwit | Matthias247: put everything in one module, then export what you need. If the module gets too big, divide up the files and then 'include' them into one module |
| 23:19:01 | * | xenagi joined #nimrod |
| 23:19:13 | Matthias247 | filwit: that seems the most reasonable way |
| 23:19:25 | filwit | Matthias247: you can put all the sub-files in their own folder for organization, too. |
| 23:20:22 | skyfex | Araq: I see that "break" inserts a copy of the finally blocks it must execute when it breaks out of a try..finally statement. I'm curious, is it impossible to do it so that the code is shared? |
| 23:21:37 | Araq | skyfex: I think so |
| 23:21:54 | Matthias247 | can imports be somehow done with aliases in case there would be multiple modules with the same name? like import A as B ? |
| 23:21:56 | Araq | not too sure but the naive 'goto' surely doesn't work |
| 23:22:17 | filwit | Matthias247: yes, with that exact syntax i believe |
| 23:22:27 | skrylar | Matthias247: you can 'from X import nil' which also requires the qualified name |
| 23:22:33 | filwit | ^ that too |
| 23:23:50 | Matthias247 | hmm, but you then would also somehow need to specify a filename for A and A' ? |
| 23:24:23 | Matthias247 | sorry for the hypothetical questions, just curious :) |
| 23:24:41 | filwit | there might be a way to do 'from A import nil as B' but i'm not sure |
| 23:25:53 | filwit | not that it matters much, the 'import nil' thing isn't worth much considering it simply enforces using the module name even if there's not ambiguity |
| 23:26:27 | filwit | (shhh.. Araq. I know i'm a hypocrite :P) |
| 23:27:03 | Varriount | filwit: I'm sure your musings are making someone, somewhere, squirm in their seats |
| 23:27:17 | filwit | :) |
| 23:29:02 | Varriount | Araq: Has the bug involving yielding within an iterator, when not in a loop in an iterator, been solved? |
| 23:31:41 | Araq | Varriount: dunno |
| 23:31:56 | Varriount | Araq: I'm trying to find the bug. |
| 23:33:12 | Varriount | Araq: https://github.com/Araq/Nimrod/issues/140?source=cc |
| 23:33:27 | * | sale4one quit (Remote host closed the connection) |
| 23:36:37 | filwit | Matthias247: this is often what i do for organization within modules: https://gist.github.com/PhilipWitte/9026767 |
| 23:36:43 | EXetoC | Araq: GCC conditionally defines namespaces in certain headers -.- |
| 23:37:07 | EXetoC | surely that's not standard. don't we have cstdio etc for that? |
| 23:38:00 | * | darkf joined #nimrod |
| 23:38:48 | EXetoC | actually, it's just a matter of injecting std, though I can't remember if it works when such a namespace isn't present |
| 23:38:56 | Matthias247 | filwit: hmm, why don't you need to export the other new methods? |
| 23:39:29 | EXetoC | no that can't be a good idea |
| 23:41:03 | filwit | Matthias247: i do, was a typo |
| 23:42:29 | filwit | Matthias247: i was just showing that I make one type the same name as the module, and use it as the 'main' type in the module (meaning it's allocation procs don't get prefixed with 'typdesc'). That way, referencing the type itself and referencing the module name usually appear to be referencing the same construct. |
| 23:43:40 | filwit | Matthias247: eg, 'Canvas.Mesh' (here 'canvas' is the module name) vs 'Canvas.new()' (here 'canvas' is the type name) |
| 23:43:43 | Matthias247 | but what would be different if you would use new(T:Color) directly? |
| 23:44:31 | Matthias247 | ehm, new(): TColor |
| 23:45:02 | filwit | Matthias247: cause then the proc names collide if they accept the same parameters. |
| 23:45:20 | EXetoC | yeah, we don't have return-type overloading |
| 23:45:32 | filwit | Matthias247: the classic way (the way most people write Nimrod code) is to do 'newMesh', 'newColor', etc |
| 23:45:52 | Matthias247 | ah, the info from EXetoC was what I was missing :) |
| 23:46:56 | Matthias247 | so this would be somehow an equivalent to a static class method? |
| 23:47:08 | filwit | though return-type overloading is planned, just not in the immediate future (sometime after 1.0 is released, apparently). When that is the case, I will use 'var c: Canvas = new(...)' |
| 23:47:24 | filwit | Matthias247: yes, basically |
| 23:56:43 | * | skyfex quit (Ping timeout: 272 seconds) |
| 23:58:18 | EXetoC | T(...) is very compact, and that's why I like it |
| 23:58:36 | * | skyfex joined #nimrod |