postpone discussion.
Hi, I just want to mention that I really wan't input from more people. Therefore I highlighted the postpone facility I made on Advogato to see if I can get any reactions. I've tried on the #prolog list as well and got some clues from them. But as far as I understand the postpone facility is right now quite unique for the unify-guile repo. The postpone facility is now considerably more firm in it's grounds. And I've just checked in code so that now we have. 1. recursive postpone frames 2. customizable searches of newframes. So just to see those in action, consider making a chess solver (again heh) Assume that we have a function potential : State - Number, And state is some complex datastructure that are builed during the game. State may be large and we want to tree compress that structure. Also we would like to dive deeply in strategically interesting paths. Now, we introduce a token flow onto the tree. The difference now is that postpone has an token argument, e.g. and we have something like my_postpone :- potential(X), postpone(X). we here call potential and put that into X (ouch, my functional liver is in delerium) and then call postpone with an argument. This means that the end of the branch will start with a token state of the potential value. There is a scheme function gp-unwind-token that the c-code hooks into at a branch while unwinding. it is a function f : X,X - X, X is the token space. e.g. the result of that function is a new token representing the combined tree for our case we would like to know the maximum token value in order to understand if it's worth diving down into the branch later on. so ... (define (gp-unwind-token Br1 Br2) (max Br1 Br2)) Other choises is Min , expanding intervalls, and a plain cons if the initial token is a symbol (hence having a set of symbols you can find the redos associated with them) Now, the current search function (to execute the redos) has the forms search(start) - ((id . tok1) . (id . tok2)) - at branch search(start) - lambda - at leaf search(start) - EOL - at end we conclude from the initial token a Maxum value of V, then we can choose to execute all tokens in the intervall [V,0.9V] in a new postpone frame that never executes postpones at a lower level of 0.9V. And as we see from the result from a search at a branch we can see if there is potential tokens in the branch that match the search criteria and go there if present. When there are no more postpones in a frame, the rest of the postpones should hooke onto the previous frame and continues as before with the previous frame. Cool right! Now, recursive postpone frames is implemented. I have the code set up for a token version of the search. After that I need to adjust the code slightly to move up the leafs with f 0.9V and then we should have this functionality in place. Probably for some interesting applications there will be a hughe demand on memory. And Keeping the redo tree slim can have a great cost benefit. I believe it is possible to save like 4x in space. And certaily 2x if guile was on a 32bit. Now it might be interesting to have guile in 64bit, but let guile sit on a 32 bit adress subspace. And only let the redo tree take advantage of adressing more then 32bits. This would logically save 2x of memory space. So is it possible to accomplish this? Hope this was stimulating. Regards Stefan
Re: decrufting: libguile/version.h generation
Hi Guilers! Thien-Thi Nguyen t...@gnuvola.org writes: * configure.ac (AC_CONFIG_FILES): Add libguile/version.h. * libguile/Makefile.am (version.h): Delete target. (EXTRA_DIST): Remove version.h.in. (BUILT_SOURCES): Remove version.h. (MOSTLYCLEANFILES): Remove version.h, version.h.tmp. * libguile/version.h.in (SCM_MAJOR_VERSION): Use conventional @VAR@ instead of @-VAR-@ for ‘GUILE_MAJOR_VERSION’. (SCM_MINOR_VERSION, SCM_MICRO_VERSION, SCM_EFFECTIVE_VERSION): Likewise for ‘GUILE_MINOR_VERSION’, ‘GUILE_MICRO_VERSION’, ‘GUILE_EFFECTIVE_VERSION’. Fine with me, please push! Ludo’.
Re: [PATCH] Support for SRFI 27
Hello! Andreas Rottmann a.rottm...@gmx.at writes: Attached is my take on adding SRFI 27 Sources of Random Bits. Nice! Looks good to me. Could you also add a node to doc/ref/srfi-modules.texi? +;; These tests are commented out since it /could/ happen that +;; `random-source-randomize!' (or `random-source-pseudo-randomize!') puts the +;; RNG into a state where it generates the same number as before. If you run +;; them manually, they should have a very high chance of passing, though. Perhaps you could run them anyway and throw 'unresolved when they appear to fail? The guardian tests do that when it’s impossible to determine whether it’s a failure or whether some unrelated phenomenon prevented the test to pass. Thanks, Ludo’.
Re: PEG Parser Updates/Questions
On Fri, Aug 6, 2010 at 1:40 AM, Michael Lucy michaelgl...@gmail.com wrote: On Wed, Jul 28, 2010 at 12:13 AM, Michael Lucy michaelgl...@gmail.com wrote: I've officially eliminated the last define-macro expression. However, I get the feeling that things may not be exactly as desired. The original program made extensive use of functions in building the macros, and I originally tried to replace these with macros. This turned out to be a little difficult to debug, however (read: I was unable to make the code actually work). I eventually abandoned this and just made datum-syntax calls. I've left this alone since then; it would be nice to get some confirmation that this was the right choice though. If it isn't, I think I still have time to change it before the GSOC deadline (and like I said, I'll hang around after it). So, we're essentially at the GSOC deadline. I pushed up the finished form of what I have to the git repository, plus some benchmarks. I also added a variant on packrat parsing using a cache instead of a hash (the hash performs poorly on flat text files). This turned out to be well worth it; on the relatively limited benchmarking suite it was about a 50x performance boost. Quick summary of files added (all in origin/mlucy): Actual module: module/ice-9/peg.scm Test suite: test-suite/tests/peg.test Benchmarks: test-suite/tests/peg.bench (wasn't quite sure where to put this) Documentation: doc/ref/api-peg.texi (also updated guile.texi to include it) The macros haven't been touched (except I fixed up one define-macro macro that had slipped past my radar). I'll be hanging around after the deadline tidying up a bit more (I'd like some more benchmarks); if the macro situation isn't what you guys want I'll fix it. Anyway, I just pushed up everything I have to the git repository (I think; I may have screwed up the syntax). I'm basically done except that the documentation/comments could use some more touching up, I don't have a set of benchmarks yet and I haven't really optimized things all that much. On the one hand, this works. I also find it easier to debug, and I think it looks cleaner. The downside is that one doesn't get all the same benefits of referential transparency, so I still have gensyms in the functions etc. Is this a problem? If so, I can definitely replace everything with macros, but I might not be able to do that and get everything else done by the GSOC project deadline. I'd like to hang around after the project is officially done from Google's point of view to polish things up, so I could also do it then. Another question about module namespaces: I have some syntax that I'd like to be available to code generated by macros in my module, but which I'd rather not export to the user (to avoid clobbering their functions). Is there a standard way of doing this? I can't seem to find anything in the module documentation regarding giving namespaces to things in modules except for :renamer, which has to be done by the user--the only options appear to be not exporting it at all, or exporting it straight into the user's namespace. The best fix I can think of is naming the syntax things the user is unlikely to ever take (or maybe using gensyms to make sure it isn't a name they take).
