| 00:51:54 | * | Trixar_za is now known as Trix[a]r_za |
| 02:10:46 | * | XAMPP[0] quit (Ping timeout: 246 seconds) |
| 08:46:19 | * | JStoker quit (Excess Flood) |
| 08:47:46 | * | SchalaZeal joined #nimrod |
| 08:48:10 | SchalaZeal | Does anyone know how to pass an array to a proc expecting a pointer parameter? |
| 08:50:59 | Tasser | SchalaZeal, addr() gives you the pointer |
| 08:51:29 | SchalaZeal | Ah, thanks |
| 08:57:47 | * | JStoker joined #nimrod |
| 09:05:26 | SchalaZeal | cmd.exe....... weirdest thing ever |
| 09:06:07 | SchalaZeal | part of the data in the stream I sent over a socket, when I echo'd it appeared as different variants of smiley face symbols |
| 09:06:50 | SchalaZeal | but other than that, I got the behavior I wanted |
| 09:11:28 | SchalaZeal | I'm in the process of trying to code some more internet protocol modules to contribute |
| 09:11:50 | SchalaZeal | since IRC is the only one |
| 09:12:35 | Tasser | SchalaZeal, powershell? ^^ |
| 09:12:51 | Tasser | SchalaZeal, http? :-) |
| 09:14:00 | SchalaZeal | well... uhm... were you on the internet in the late 90s? |
| 09:14:55 | SchalaZeal | cause I just wrote a minimalistic client for a protocol called Hotline that's pretty much....ancient |
| 09:15:11 | SchalaZeal | but was innovative back in the 90s |
| 09:17:14 | Tasser | they had internet back then? :-) |
| 09:17:39 | SchalaZeal | http://pastebin.com/H5eJFJQr |
| 09:18:22 | SchalaZeal | all it does is do a successful handshake if its connection to one of the few remaining servers on there is successful |
| 09:19:10 | SchalaZeal | sends the message TRTP and 2 int16s with the values 1 and 2 |
| 09:19:34 | SchalaZeal | should receive from the server TRP and an int16 with the value 0 |
| 09:19:39 | SchalaZeal | err TRTP** |
| 09:19:48 | SchalaZeal | oops |
| 09:19:56 | SchalaZeal | it sends TRTPHOTL I meant |
| 09:20:03 | SchalaZeal | hehe |
| 09:21:19 | SchalaZeal | it needs to be able to handle transactions if it's going to be actually useful though |
| 09:22:06 | SchalaZeal | that's what I'm going to be going with my 'hotline' module |
| 09:22:56 | SchalaZeal | doing** |
| 09:25:09 | SchalaZeal | Protocol documentation is at http://hotline.wikia.com/wiki/Protocol and http://hotline.wikia.com/wiki/Virtual1%27s_Hotline_Server_Protocol_Guide |
| 09:36:29 | Tasser | never heard of |
| 09:44:04 | SchalaZeal | eh it was one of those underrated things |
| 09:44:30 | SchalaZeal | 1 million users at its peak I think |
| 09:45:42 | SchalaZeal | plus I think a Second Life server written in Nimrod would be far too difficult, if not impossible |
| 09:48:23 | SchalaZeal | Not that I think Nimrod's incapable of doing that but........ I have yet to see anyone do something major with it such as an MMO or.......something |
| 09:48:54 | SchalaZeal | most I've seen is a space invaders clone |
| 09:49:28 | SchalaZeal | err most complex rather |
| 09:52:05 | SchalaZeal | I have no doubt it has more potential of course. Nimrod's just under the radar right now. Wikipedia page got deleted even |
| 10:01:17 | Tasser | ouch |
| 10:14:10 | SchalaZeal | yeah |
| 10:14:42 | SchalaZeal | anyway... got an outline for the module..... tomorrow I code..... if it's too hot to learn 3D modelling some more |
| 10:15:27 | SchalaZeal | guten nacht everyone |
| 10:15:31 | * | SchalaZeal quit () |
| 10:51:34 | * | zahary quit (Ping timeout: 246 seconds) |
| 14:46:58 | * | XAMPP joined #nimrod |
| 18:43:59 | * | zahary_ joined #nimrod |
| 19:29:21 | Araq | hi zahary_ |
| 19:50:34 | * | XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.) |
| 19:51:14 | * | XAMPP joined #nimrod |
| 19:51:15 | * | XAMPP quit (Changing host) |
| 19:51:15 | * | XAMPP joined #nimrod |
| 20:07:43 | Tasser | Araq, hmm, do you plan on implementing anything like interfaces? |
| 20:07:57 | Araq | I have a deja-vu ... |
| 20:08:02 | Tasser | yep, I know :-) |
| 20:08:08 | Araq | use a tuple of closures |
| 20:08:16 | Tasser | huh? |
| 20:08:21 | Araq | they should work by now |
| 20:11:17 | Tasser | got an example somewhere? |
| 20:11:40 | Tasser | I don't see how a tuple of closures gives me an interface |
| 20:14:56 | Araq | there is an example on the forum somewhere :P |
| 20:16:00 | Tasser | hum |
| 20:16:38 | Araq | http://forum.nimrod-code.org/t/31 |
| 20:17:56 | Tasser | hum |
| 20:18:39 | Tasser | I see interface as a solution to the "I require a data type that has a function called X and one called Y" problem |
| 20:19:36 | Araq | I see an isomorphism between "tuple of closures" and "interface" :P |
| 20:19:54 | Tasser | ^^ |
| 20:20:31 | Tasser | would be nice to have some support for that problem by the type system though |
| 20:21:47 | Araq | yeah but the problem is: |
| 20:22:19 | Araq | Nimrod's creator despises any form of dynamic binding |
| 20:22:50 | Tasser | and callbacks? |
| 20:24:26 | Araq | it doesn't matter if it's a "callback" or a "function pointer" or a "closure" or an "interface" or a "multi method" or an ordinary "method" |
| 20:24:50 | Araq | it's a necessary evil ;-) |
| 20:24:58 | Araq | but I will never embrace them |
| 20:25:27 | Tasser | I'm not exactly sure how Gos type system works... does it assign types by functions defined? |
| 20:26:05 | Araq | it more or less attached procs to a type for the interfaces to work |
| 20:26:26 | Araq | as the procs must be in the same module (or perhaps package) |
| 20:26:50 | Tasser | and I suppose dynamic types would be the evil himself? ^^ |
| 20:27:25 | Araq | well as usual you should be able to do something with macros and converters |
| 20:27:49 | Araq | convert toIface(x: MyObject): MyInterface |
| 20:28:00 | Tasser | you loose MyObject as type information |
| 20:28:11 | Araq | that's the point |
| 20:28:17 | Araq | isn't it? |
| 20:29:04 | Tasser | it's not to replace the type, but rather add a new one without removing the old one |
| 20:29:27 | Araq | btw Ada 83 had no function pointers nor any other means to get a callback afaik |
| 20:29:54 | Araq | as that enables tools to get a *complete* call graph |
| 20:30:04 | Araq | and you can then prove the heck out of your code |
| 20:31:01 | Tasser | what's the approach to the problem a callback solves? (call a function whenever X happens) |
| 20:31:30 | Araq | in Ada83 you would work around with an event dispatching mechanism I think |
| 20:31:38 | Araq | think of how SDL does it |
| 20:31:53 | Tasser | uhm, information leak there |
| 20:32:11 | Tasser | where do I read up how SDL does it? |
| 20:32:24 | Araq | while peekEvent(ev): |
| 20:32:31 | Araq | case ev.typ |
| 20:32:37 | Araq | of mouseClick: ... |
| 20:32:40 | Araq | etc. |
| 20:32:57 | Araq | you get the idea |
| 20:33:17 | Tasser | so when the event happens, you don't go down but up the call stack |
| 20:33:56 | Araq | more or less |
| 20:34:10 | Araq | you store the event in a queue and let the client ask for it |
| 20:34:52 | Araq | "tell don't ask" is not good for verification |
| 20:35:16 | Araq | but I digress |
| 20:35:49 | Tasser | isn't iterator chaining kind of a callback? |
| 20:36:29 | Araq | what do you mean? |
| 20:36:44 | Araq | nimrod's iterators don't use callbacks |
| 20:36:54 | Araq | and Ada83 does not even have iterators |
| 20:38:14 | Araq | however |
| 20:38:25 | * | zahary_ is now known as zahary |
| 20:38:30 | zahary | hi |
| 20:38:31 | Araq | callbacks are actually easier to analyse than (multi) methods |
| 20:38:51 | Araq | as the dispatching is harder to track for methods |
| 20:39:12 | Araq | zahary: is the C++ exception handling working and stable? |
| 20:40:35 | zahary | I haven't tested it much, but I don't see many things that could go wrong with it (also, nimrod bootstraps fine with it enabled) |
| 20:41:29 | Araq | bootstrapping is not a very good test for exceptions |
| 20:41:42 | Araq | much better is "nimrod check" with an errornous file |
| 20:41:46 | zahary | well, there are some try blocks in the compiler |
| 20:42:17 | Araq | yeah but "nimrod check" or "nimrod suggest" actually triggers them |
| 20:44:05 | zahary | I was thinking about running the test suite in cpp mode (also in "nimrod i" mode too) |
| 20:46:33 | Araq | that's a good idea :-) |
| 20:46:57 | Araq | "nimrod i" won't fly for the test suite, but "cpp" should be easy |
| 20:48:06 | Araq | I could some simple tests to work with the JS backend and node.js :D |
| 20:48:34 | Araq | exceptions are still quite broken in the JS backend |
| 20:48:46 | zahary | I've tried nimrod i manually on some tests and it works most of the time |
| 20:49:18 | zahary | my guess is that there will be some false positives, but it's likely to reveal some bugs in the interpreter too |
| 20:49:46 | Araq | but lots of tests use "system.write[ln]" for a start |
| 20:49:58 | Araq | and we still have no IO support |
| 20:51:37 | zahary | they could be written to use echo instead - you used system.write to avoid newlines, but if that's desired maybe the tester could simply ignore newlines in the output if told so |
| 20:52:23 | Araq | try but the tester actually now supports newlines |
| 20:52:42 | fowl | how do i bring a union from c |
| 20:53:05 | Araq | fowl: c2nim can do it ;-) |
| 20:53:18 | Araq | well not really; it uses the first field of the union |
| 20:53:30 | Araq | in the hope that it has the maximum size |
| 20:53:51 | zahary | fowl, in general you cheat and add overloads and unsafe casts to represent the alternative fields |
| 20:54:47 | fowl | that doesnt sound fun :< |
| 20:55:01 | Araq | yeah, C interfaces with everything very well; until you take a closer look ;-) |
| 20:55:49 | Araq | fowl: most APIs do not require you to access the union's fields directly |
| 20:56:07 | Araq | it's often enough to get the size of union right |
| 20:58:07 | fowl | im working on porting allegro, so far it loads and displays images |
| 20:58:25 | Araq | awesome |
| 20:58:27 | zahary | fowl, you can have a template to automate the dirty work |
| 20:58:27 | zahary | template union_view(T: typedesc, field, field_type: expr) = |
| 20:58:27 | zahary | proc `field`(x: var T): var field_type = |
| 20:58:27 | zahary | result = cast[ptr field_type](addr(x))[] |
| 21:05:34 | Araq | zahary: I'm thinking (and in fact writing some code) about the matching of ASTs |
| 21:05:40 | Araq | for the HLO |
| 21:06:27 | Araq | and the patterns are hard to match I think |
| 21:06:34 | zahary | I hope it's in sem.nim :) |
| 21:06:48 | Araq | it's in a separate module for now ;-) |
| 21:06:59 | Araq | but that's what I'd like to talk about |
| 21:07:13 | Araq | there are 2 use cases, much like for macros |
| 21:07:26 | Araq | immediate vs "ordinary"/after type checking |
| 21:07:51 | Araq | but "immediate" really causes problems for term rewriting |
| 21:08:48 | zahary | what kind of problems? |
| 21:09:03 | Araq | a + b * c |
| 21:09:22 | Araq | we could make a first pass and annotate atoms with types |
| 21:09:38 | Araq | and then try to match the pattern |
| 21:10:10 | Araq | but I think it's always possible to introduce "dummy" ordinary operators |
| 21:10:22 | Araq | to make the desired expressions type check |
| 21:10:31 | Araq | and then run the pattern matching over them |
| 21:11:16 | Araq | (the example I have in mind is: proc {x + y * z} (x, y, z: float): float = ... ) |
| 21:12:31 | Araq | the pattern matching may of course rule out some combinations afterwards with the .error pragma |
| 21:12:57 | Araq | what use cases do you have in mind for "immediate" patterns? |
| 21:13:49 | Araq | for the use cases I have in mind, it always suffices to semcheck before pattern matching |
| 21:14:37 | zahary | how will matching proceed here? |
| 21:14:38 | zahary | I imagine nkInfix with * will be the "head of the pattern" - when it's encountered in sem, its children are passed to semExprWithType and then they either match the expected types or they don't |
| 21:15:15 | zahary | so the recursive nature of semExprWithType is something similar to the "first pass" you mentioned |
| 21:15:35 | Araq | well the matching is quite sophisticated as it supports unification and wildcards etc. (we talked about it) |
| 21:15:54 | Araq | and my plan is to run it as part of semcheck |
| 21:16:03 | Araq | but after overloading resolution |
| 21:16:33 | Araq | much like non-immediate templates |
| 21:17:09 | zahary | my thinking was that even the more sophistacated patterns have such a "pattern head" node that can be matched as a first step in semExpr |
| 21:17:22 | zahary | almost directly from a lookup table |
| 21:17:44 | Araq | there is not necessarily a "pattern head" |
| 21:17:59 | Araq | well ok there is |
| 21:18:04 | Araq | but it's too general |
| 21:18:14 | Araq | and all the cases I look at |
| 21:18:20 | Araq | require proper type information |
| 21:18:26 | Araq | it doesn't make sense to transform |
| 21:18:30 | Araq | x * 0 -> 0 |
| 21:18:36 | Araq | if you don't know x's type |
| 21:19:30 | Araq | macros get around it as they then work like keywords |
| 21:19:44 | Araq | but this doesn't work for generalized patterns |
| 21:21:02 | zahary | I think a good parallel would be if you think about nkIfix as some kind of proc that participates in overload resolution |
| 21:21:02 | zahary | when you encounter it and there is a pattern that uses it as head you just try to apply the "standard" overload resolution algorithm over the node |
| 21:21:11 | zahary | you treat the sons as params |
| 21:21:57 | zahary | wildcards, etc are somewhat similar to varargs params in this analogy |
| 21:24:50 | Araq | say I have a ternary operator, x ? y ! z |
| 21:25:19 | Araq | an immediate pattern then is the same as a syntax extension |
| 21:25:41 | Araq | which is against nimrod's philosophy |
| 21:26:01 | Araq | since once you reach this point |
| 21:26:08 | Araq | you should use a string literal and compile-time parser |
| 21:26:50 | Araq | instead you need to make Nimrod parse and type check (x ? y) | z |
| 21:27:02 | Araq | and then you can match over it |
| 21:27:19 | Araq | er, I mean (x ? y) ! z |
| 21:28:15 | Araq | but my point is: collect use cases for your way ;-) |
| 21:28:29 | zahary | alright, but what's the problem? you imply that there must exists a separate well defined operator "?" ? |
| 21:28:38 | Araq | yes |
| 21:28:54 | Araq | in fact, we can accept 'expr' as a type |
| 21:29:09 | Araq | and require proper types only after pattern matching |
| 21:33:06 | Araq | but hm |
| 21:33:23 | Araq | "stride" was a good use case |
| 21:34:13 | Araq | x[2..4 :+ 3] # slice with step 3 |
| 21:35:03 | Araq | it's a bit annoying to make a slice[int] out of '..' and then take a slice and an int to get a stride type |
| 21:35:07 | zahary | I don't see the AST-level transformations as something bad, but even this viewpoint don't conflict too much with the "overload resolution" approach I mentioned - since overload resolution composes fine when there are multiple nested type checked calls (foo(bar(baz)) the same will be true for patterns |
| 21:36:14 | Araq | and then you have proc `[]`(x: array, s: stride) |
| 21:36:29 | Araq | only to optimize it all away in a pattern matching step |
| 21:37:06 | Araq | on the other hand, it's not to horrible I think |
| 21:37:07 | zahary | my latest thinking is that "inter-statement" patterns (the ones that merge several lines of code into 1) are more valuable than single-expression patterns since these are quite isomorphic to normal use of templates |
| 21:39:58 | Araq | but for them you need the types even moreso |
| 21:40:21 | Araq | the more complex the pattern the more useless it is |
| 21:40:31 | zahary | well, yes - do I imply somehow that the types are not needed? |
| 21:40:52 | Araq | well yes |
| 21:41:10 | Araq | as you have some different matching algorithm in mind than me :-) |
| 21:42:06 | Araq | btw what do we do with the fixpoint iteration? screw the idea? only via command line switch? |
| 21:42:16 | Araq | always do it? |
| 21:42:27 | zahary | hmm, where? I said you should do semExprWithType on the sons, before passing them to standard overload resolution algorithms |
| 21:43:09 | Araq | yes but overload resolution only handles a single call |
| 21:43:40 | Araq | and so it can be performed bottom up |
| 21:43:48 | zahary | but my point was that each pattern has a "head" that looks like a single call |
| 21:44:25 | Araq | yes |
| 21:44:31 | Araq | but how does it proceed then? |
| 21:44:38 | Araq | semExpr() = |
| 21:44:54 | Araq | if n.kind in pattern.kind: |
| 21:45:11 | Araq | ... what here ...? |
| 21:47:35 | zahary | if not patterns[n.kind].empty: |
| 21:47:35 | zahary | # try to match |
| 21:47:35 | zahary | # make sure semExprWithType is called only once for each son even tho we'll try to match several patterns |
| 21:47:35 | zahary | # maybe apply my lazy typing scheme where semExprWithType is not called if the pattern has a expr{NodeKind} param types |
| 21:47:35 | zahary | proceed |
| 21:49:38 | zahary | it also makes sense to optimize a bit further nkCalls, nkInfix, etc with additional table keyed on the first symbol |
| 21:50:27 | Araq | either I don't get it |
| 21:50:41 | Araq | or you propose the same algorithm as I do |
| 21:51:12 | Araq | as the lookup table per node kind is only an optimization? |
| 21:51:47 | Araq | which I'm not worried about for now |
| 21:52:39 | zahary | maybe I was fouled by what you meant by "after overload resolution" - I imagined that you run semExpr to end and then you try to do some additional steps with the results |
| 21:53:23 | zahary | what I suggest is that this is an alternative path in semExpr - you either exit through the pattern match path or though the current path |
| 21:54:10 | Araq | hm yes |
| 21:54:16 | Araq | but it's the same: |
| 21:54:40 | Araq | you have a pattern's "head" |
| 21:54:47 | Araq | you semExpr every son |
| 21:55:25 | Araq | the pattern fails, but you ensure semExpr is called only once (per flag I assume) |
| 21:55:41 | Araq | ordinary semExpr proceeds |
| 21:56:00 | Araq | and then you need to check for the pattern again |
| 21:56:12 | zahary | proceed if the pattern didn't match is what I meant |
| 21:56:14 | Araq | as the pattern's head is not nearly enough |
| 21:56:41 | Araq | yeah I'm talking about the case where the pattern doesn't match in semExpr |
| 21:56:47 | Araq | but afterwards |
| 21:58:52 | Araq | there is a difference if the pattern matches in the first pass already |
| 21:59:45 | Araq | but maybe I still don't get it: |
| 21:59:53 | Araq | a!b!c |
| 21:59:59 | Araq | is (a!b)!c |
| 22:00:11 | Araq | in the tree representation |
| 22:00:53 | Araq | or lets make it a!(b!c) |
| 22:01:07 | Araq | for my explanation |
| 22:01:19 | Araq | so you semExpr 'a' |
| 22:01:35 | Araq | and then you semExpr 'b!c' |
| 22:01:50 | Araq | but this fails if you have no binary operator '!' |
| 22:01:59 | Araq | you can't do |
| 22:02:10 | Araq | template {a!b!c} ... |
| 22:02:16 | Araq | and expect it to work |
| 22:02:19 | zahary | well, the head head is nkInfix ! |
| 22:03:05 | zahary | it expects 1 typed son and a "subpattern" - another nkInfix ! |
| 22:03:21 | zahary | * the head here * |
| 22:03:45 | Araq | ah |
| 22:03:49 | Araq | I finally got it |
| 22:04:05 | Araq | so you basically check for the AST structure first |
| 22:04:14 | Araq | and then you if the structure matches |
| 22:04:20 | Araq | you perform semExpr |
| 22:04:26 | Araq | on the sons (deeply) |
| 22:04:35 | Araq | and then you check the types match for the pattern? |
| 22:04:52 | zahary | yes, I would say you check the AST structure and the types in parallel in the recursive process |
| 22:05:07 | Araq | argh |
| 22:05:31 | Araq | so you check them in parallel ... hm |
| 22:09:42 | Araq | I will think about this :-) |
| 22:09:52 | Araq | but again: |
| 22:09:58 | Araq | what's the actual use case for this? |
| 22:10:48 | Araq | if you build the DSL piece by piece as pegs does it |
| 22:11:01 | Araq | and you then have optimizing patterns |
| 22:11:08 | Araq | you gain composability |
| 22:11:36 | fowl | how long have you two been programming |
| 22:11:41 | Araq | and it's much easier to understand and you can pass subexpression as first class objects |
| 22:12:18 | zahary | well, I see this as relatively efficient implementation of the HLO (and also consistent with the rest of the language, because it will reuse the algorithms in sigmatch) - otherwise the use cases are what we have discussed already |
| 22:12:36 | Araq | well it's been a while |
| 22:13:13 | Araq | I can only remember *my* examples :-/ |
| 22:13:34 | Araq | and they all work fine with my somewhat simpler approach |
| 22:14:25 | zahary | some use cases from the top of my head |
| 22:14:25 | zahary | 1) eliminating temporary objects in expressions like |
| 22:14:25 | zahary | "a" & "b" & "c" (with other types and operations similar in costs to string concatenation) |
| 22:14:55 | Araq | that's the standard use case :-) |
| 22:15:33 | Araq | fowl: I've been programming for 12 years I think |
| 22:15:48 | Araq | maybe for 14 years |
| 22:16:02 | zahary | I probably for 10 |
| 22:17:16 | Tasser | wow |
| 22:19:38 | Araq | I have to sleep soon |
| 22:19:40 | zahary | my a bit less standard examples were proxy types and the Option[T] optimizations |
| 22:19:40 | zahary | var o: Option[T] = something |
| 22:19:40 | zahary | if o: # pattern match here to establish that the option is "proven" existent in the block |
| 22:19:40 | zahary | # use the dependent type information to elimate any further checks |
| 22:20:16 | Araq | that's insane ;-) |
| 22:20:54 | Araq | you need more than the HLO to do that I think |
| 22:21:14 | Araq | well it depends on the wildcard capabilities |
| 22:22:15 | Araq | but you need to ensure 'o' is not re-assigned |
| 22:22:28 | Araq | so it only works with 'let' etc. |
| 22:23:21 | Araq | and the question remains: if you do it interlocked with the rest of semantic checking |
| 22:23:23 | zahary | that's how my hypolang was supposed to work - you can overlay the "if call" to set compile time property in the block |
| 22:23:23 | zahary | new assignment will wipe out the value of the compile time property |
| 22:24:00 | Araq | then how do specify the fixpoint computation? |
| 22:24:34 | zahary | can you clarify what do you mean by that? |
| 22:24:55 | Araq | in the old HLO design I had an iteration step |
| 22:25:12 | Araq | it would only stop if there are no optimizations left to perform |
| 22:25:30 | Araq | or some counter overflowed to prevent endless loops |
| 22:25:47 | Araq | the counter was by pattern, so every pattern may trigger -say- 100 times |
| 22:26:02 | zahary | so the question is what are the terminating conditions? |
| 22:26:29 | Araq | the question is whether you want that to introduce into the semantic checking phase ... |
| 22:26:39 | Araq | but I can guess your answer ... |
| 22:27:24 | Araq | and the next question is *why* we need a fixpoint computation in the semantic checking phase; it can only hurt IDE support |
| 22:27:54 | Araq | I don't want the compiler to do crazy optimizations for doing intellisense |
| 22:30:09 | Araq | I guess the real question is: |
| 22:30:24 | Araq | what use cases are there that are *not* optimizations? |
| 22:32:26 | Araq | *cough* for optimizations my old design was quite good (on paper at least)... |
| 22:32:58 | Araq | but I have to sleep now |
| 22:33:00 | zahary | well, the proxy types are not optimizations and they could be considered patterns with nkCall head |
| 22:33:33 | zahary | I surely can come up with varios perverse DSL uses, but you probably wont like these :) |
| 22:33:55 | Araq | ah maybe |
| 22:34:19 | Araq | but yeah I forgot about the AOP stuff |
| 22:37:13 | Araq | so yeah tell me your perverse DSL uses tomorrow |
| 22:37:18 | Araq | good night |
| 22:37:49 | zahary | good night |
| 23:11:13 | * | Trix[a]r_za is now known as Trixar_za |
| 23:26:17 | * | SchalaZeal joined #nimrod |
| 23:27:21 | SchalaZeal | Having some trouble with arrays and pointers. I know in C, you can use a pointer as an array. However I don't know what to do in Nimrod |
| 23:30:15 | Trixar_za | Araq probably wrote in a way to do the same in Nimrod, but I'm not sure how to do that. Most of them have gone to bed though, SchalaZeal. |
| 23:30:36 | SchalaZeal | hmm ok |
| 23:31:01 | Trixar_za | Just post it on the forum and they'll get to it tomorrow |
| 23:31:09 | SchalaZeal | ok |
| 23:31:22 | Trixar_za | or in my case, today, since it's 1:30am :P |
| 23:38:24 | SchalaZeal | heh |