Thu, 26 Jun 2014 11:24:06 +0200 hi all Thu, 26 Jun 2014 12:07:16 +0200 OmniMancer: hi!" Thu, 26 Jun 2014 12:43:24 +0200 hi jonnymind Thu, 26 Jun 2014 12:43:28 +0200 how goes? Thu, 26 Jun 2014 12:43:47 +0200 do we have code to generate permutations of a given length? Thu, 26 Jun 2014 12:45:09 +0200 yes, the ^[] operator does that. Thu, 26 Jun 2014 12:45:35 +0200 ^[ s1, s2, s3...] creates all the permutations in the given sequences. Thu, 26 Jun 2014 12:45:48 +0200 and sequences can be anything iterable, from ranges to generators. Thu, 26 Jun 2014 12:46:10 +0200 the filter function can then filter out the permutations you don't want. Thu, 26 Jun 2014 12:47:09 +0200 (or, actually, transform any permutation, if you return oob) Thu, 26 Jun 2014 12:53:18 +0200 what if I want permutations of length 3 from N things? Thu, 26 Jun 2014 12:57:41 +0200 OmniMancer: I suppose a function would be more adequate. Thu, 26 Jun 2014 12:58:55 +0200 I think there is an array function doing that, like [...].permute(3) Thu, 26 Jun 2014 12:59:15 +0200 you actually want a N permutation out of a set of M items, right? Thu, 26 Jun 2014 13:00:56 +0200 Uhm, no, we don't have it right now, but it should be relatively easy to add. Thu, 26 Jun 2014 13:01:12 +0200 creating the permutations from iterable sets is WAY more complex. Thu, 26 Jun 2014 13:01:17 +0200 yes Thu, 26 Jun 2014 13:01:26 +0200 yea Thu, 26 Jun 2014 13:01:27 +0200 extracting the permutation of a set can be done in a single function. Thu, 26 Jun 2014 13:01:49 +0200 I found some C++ code that does it by taking each combination of N of the AM items Thu, 26 Jun 2014 13:01:50 +0200 Array.permute would be correct english or shall that be permutate? Thu, 26 Jun 2014 13:01:54 +0200 them permuting it Thu, 26 Jun 2014 13:01:58 +0200 permute. Thu, 26 Jun 2014 13:02:08 +0200 permute is correct AFAIK Thu, 26 Jun 2014 13:02:27 +0200 In italian is permutare, so I wasn't sure (and in latin, btw). Thu, 26 Jun 2014 13:03:04 +0200 OmniMancer: I'd be glad if you can add the function to the ClassArray. Thu, 26 Jun 2014 13:06:45 +0200 :/ Thu, 26 Jun 2014 13:07:01 +0200 I might when I rewrite my thing that uses it in falcon Thu, 26 Jun 2014 13:07:21 +0200 I need it to assign a set of special roles to a group of players in a game Thu, 26 Jun 2014 13:07:32 +0200 and you need every possible assignment Thu, 26 Jun 2014 13:08:16 +0200 It's a useful generic function. Thu, 26 Jun 2014 13:08:56 +0200 And I don't see any reason not to have it in the engine. Thu, 26 Jun 2014 13:09:13 +0200 (the code is bloated enough for that not to be a worry) Thu, 26 Jun 2014 13:09:52 +0200 Btw I am doing the parser for the parser... Thu, 26 Jun 2014 13:09:59 +0200 FILE :- {Tree()}. Thu, 26 Jun 2014 13:10:01 +0200 ELEMENT :- TITLE | TEXT. Thu, 26 Jun 2014 13:10:03 +0200 TITLE :- r"^======"m TEXT:node r"=*" EOL { node.type = "h6" }. Thu, 26 Jun 2014 13:10:05 +0200 this stuff. Thu, 26 Jun 2014 13:10:09 +0200 pretty easy now with the MultiTokenizer. Thu, 26 Jun 2014 13:10:52 +0200 The only "problem" is that atm I can't build a full module "easily", Thu, 26 Jun 2014 13:11:08 +0200 either I sinthetize the whole of the code, and I don't really feel like doing that, Thu, 26 Jun 2014 13:11:17 +0200 or you can't do... Thu, 26 Jun 2014 13:11:27 +0200 { import from struct.tree } in a preamble and then Thu, 26 Jun 2014 13:11:35 +0200 TEXT :- {Node("text")} . Thu, 26 Jun 2014 13:12:20 +0200 OTOH, we can pretty do that dynamically, Thu, 26 Jun 2014 13:12:35 +0200 as I can expand the codes in a function like { context, ... => ...} Thu, 26 Jun 2014 13:12:45 +0200 you can setup your context in the preamble with things like Thu, 26 Jun 2014 13:13:02 +0200 context = p{ Node = import(...) } Thu, 26 Jun 2014 13:13:18 +0200 and then simply TEXT :- {context.Node(...)} Thu, 26 Jun 2014 13:13:29 +0200 for the time being, fair enough. Thu, 26 Jun 2014 13:13:59 +0200 then, in 1.0 final we'll have a better reflection of the Module entity, and we could synthetize a whole module out of this easily. Thu, 26 Jun 2014 13:26:31 +0200 :) Thu, 26 Jun 2014 14:04:14 +0200 looks interesting so far Thu, 26 Jun 2014 14:36:13 +0200 jonnymind yo Thu, 26 Jun 2014 15:21:37 +0200 yo AlexRou Thu, 26 Jun 2014 15:21:44 +0200 Sorry for the delay didn't have speakers onĂ¹ Thu, 26 Jun 2014 15:22:10 +0200 The grammar parser is on Thu, 26 Jun 2014 15:22:20 +0200 Testing and finishing the last details. Thu, 26 Jun 2014 15:22:43 +0200 Now I have to use the generated grammar structure to parse files, but that is almost the easiest thing. Thu, 26 Jun 2014 15:38:15 +0200 I committed it to the new_genparser branch Thu, 26 Jun 2014 15:38:36 +0200 There's still a bit of work to do , but the grammar parser mostly works. Thu, 26 Jun 2014 15:38:50 +0200 with error detection and forward declaration resolution. Thu, 26 Jun 2014 15:38:53 +0200 pretty nice. Thu, 26 Jun 2014 15:39:05 +0200 nice Thu, 26 Jun 2014 15:39:46 +0200 soo any updates on the gc? Thu, 26 Jun 2014 15:43:12 +0200 Nope Thu, 26 Jun 2014 15:43:19 +0200 all work concentrated here atm. Thu, 26 Jun 2014 15:43:23 +0200 kk Thu, 26 Jun 2014 15:43:53 +0200 oso i have to create a context each time i want to run smth, maybe related? Thu, 26 Jun 2014 16:00:42 +0200 Uhm, technically it shouldn't be strictly necessary to create a new context each time you need to run a function, Thu, 26 Jun 2014 16:01:32 +0200 but since I didn't use the new engine to run spot code (i.e. embedding) much in this stage, Thu, 26 Jun 2014 16:01:40 +0200 I preferred to use that approach, Thu, 26 Jun 2014 16:01:48 +0200 also because when a context is done, is done for good. Thu, 26 Jun 2014 16:02:15 +0200 As I said, the best approach would be that of having a script runningg and then go to sleep, Thu, 26 Jun 2014 16:02:23 +0200 k Thu, 26 Jun 2014 16:02:24 +0200 with you sending messages to wake it up. Thu, 26 Jun 2014 16:02:48 +0200 OTOH that requires specific coding on the script side, (or synthesis) atm. Thu, 26 Jun 2014 16:03:18 +0200 Let's say we still have to define a best practice for embedding/callbacks with this engine. Thu, 26 Jun 2014 16:04:01 +0200 On one side, creating a context for each request is safer, and also allows true multitasking in the management of each request. Thu, 26 Jun 2014 16:04:08 +0200 (leak problem apart). Thu, 26 Jun 2014 16:04:56 +0200 On the other side, is less efficient by far, so it might not be a good solution for intensive usage (i.e. very frequent event processing). Thu, 26 Jun 2014 16:05:39 +0200 Might be worth going both ways: allowing heavyweight callbacks in different contexts for heavy processing that might be usefully done in parallel, Thu, 26 Jun 2014 16:05:57 +0200 and lightweight event processing that repeatedly uses the same context. Thu, 26 Jun 2014 16:07:33 +0200 I see this: Thu, 26 Jun 2014 16:07:51 +0200 a VMContext subclass and a specialized pstep that lies at the bottom of the code frame, Thu, 26 Jun 2014 16:08:09 +0200 the subclass has the ability to queue calls, i.e. it has a queue of callItem requests, Thu, 26 Jun 2014 16:08:47 +0200 the pstep reads this queue and generates a callItem on the same VMContext, or puts the context at sleep if there isn't anything to do. Thu, 26 Jun 2014 16:08:48 +0200 actually, Thu, 26 Jun 2014 16:09:19 +0200 a context is terminated when a specialized pstep pushed at its beginning is reached; that declares the context dead, Thu, 26 Jun 2014 16:09:24 +0200 and initiates the termination request. Thu, 26 Jun 2014 16:09:55 +0200 so, we can have a vmContext specialized in receiving callback requests, that never terminates Thu, 26 Jun 2014 16:10:13 +0200 (unless receiving a special request, or a normal async termination request, that kills all sleeping contexts). Thu, 26 Jun 2014 16:10:52 +0200 Async termination requests to the process do 2 things: puts all the context in terminated state and wake up sleeping contexts,. Thu, 26 Jun 2014 16:11:07 +0200 this forces the processors into giving the contexts back to the context manager, Thu, 26 Jun 2014 16:11:25 +0200 and the context manager to initiate the termination sequence of the incoming and previusly held sleeping contexts. Thu, 26 Jun 2014 16:12:17 +0200 In simple words, it means a VMContext subclass with that specialized pstep would transparently behave as we wish. Thu, 26 Jun 2014 16:22:23 +0200 This would also make room for C++ callbacks at termination of each request, Thu, 26 Jun 2014 16:22:42 +0200 where you could safely read the return value of each function, and generically, the status of the context. Thu, 26 Jun 2014 16:23:04 +0200 AlexRou: do you think you could do that? Thu, 26 Jun 2014 16:24:04 +0200 no idea Thu, 26 Jun 2014 16:24:10 +0200 still a little newish Thu, 26 Jun 2014 16:25:52 +0200 i could see what comes out but dont be expecting anything