AltME groups: search

I parse the fmod.h file and generate the commands... but in some 
cases it require manual overview so that's why some of the functions 
are still missing (and some may not work.. like the CMD_FMOD_Channel_SetSpeakerMix 
where it requires more than 7 args as an input, so I must probably 
manualy modify it. Also it's just the functions exported to REBOL, 
so it may require some more work to be more usable in real life.. 
and I must learn how to do callbacks (my next lesson)

It would also be a good place to discuss using REBOL to generate 
apps in Java (often easier than writing it directly in my experience).

Max - where do I get the dataset from, if I would try to rewrite 
your find-fast into a version using 'parse? :-) Do you generate one?

When SAVE is being used to generate source that is meant to be run 
by DO, that source should be semantically equivalent to DO code (active 
values in an evaluation context won't be preserved without QUOTE, 
nor will constructed values in a non-evaluating context). When the 
generated source is intended to be LOADed, it should stick to the 
semantics that can be directly LOADed without DO (no multi-level 
"nested scopes" or other binding tricks, no inline modules, no natives). 
And when you are going to combine them, stick to string source.

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

SAVE and MOLD are explicitly designed to be newbie-friendly - that 
includes being able to have MOLD generate the value 0.1, which is 
not representable by the (misnamed) decimal! type in memory. And 
#[] syntax has been judged to not be newbie-friendly, or at least 
an ugly thing that only power users do. If you want to reverse that 
decision, fine, but it's unlikely.

The /into option wasn't added to many applicable natives, just the 
two that generate the most data in REBOL: REDUCE and COMPOSE. That 
might be a "biggest bang for the buck" thing, or maybe we just haven't 
gotten around to it yet. Or it might be a big hassle to add /into 
to a native, so to get it done you need to justify it with use cases.

when we generate blocks on the fly, we sometimes need evaluation 
to occur at a later stage.  this allows to save on an uneeded additional 
copy.  (which can be taxing on the GC when blocks are large)

its usually better to generate larger shapes and scale them down, 
this way you have sub-pixel precision when drawing.  all you need 
to do is scale the widths and transform the coordinate space when 
you draw...

OK. The solution would be to generate an out of range error for skip 
<= 0. DIFFERENCE does that correctly.

If someone needs partial record detection, they can do it ahead of 
time. We're trying to make REBOL only generate errors when it's useful 
to do so. It was not deemed useful in this case.

Not the same thing. If you have skip > length of the series, it will 
only do one iteration and your access to the results off the end 
will usally be none, unless you constrain it yourself. The question 
is whether negative skip should be silently constrained or generate 
an error, as a general rule.

OK, Maxim, the MOVE/skip example you specify is not an error in MOVE, 
it is an error in the code calling MOVE in that example. MOVE was 
specifically designed to do something useful in that case, rather 
than generate an error.


The whole reason that MOVE takes one position and one offset is because 
that limit gets rid of a host of potential aliasing errors. MOVE 
is designed to be the most efficient and safe solution to the problem 
of moving stuff, and it should *never fail* unless the series is 
protected from changes. MOVE is a DWIM function: Do What I Mean. 
This goes for treating negative /skip lengths as an error too - having 
it magically constrain the /skip length to 1 or greater was a deliberate 
design choice, the result of a lot of discussion.


So the question is whether the error of having /skip lengths being 
less than 1 is worth worrying about, worth the overhead of generating 
an error and checking for that error every time you use the function. 
Don't be fooled, that overhead is really significant.


We've already changed other functions so they don't generate errors 
anymore, and just DWIM, like FIRST not complaining about bounds and 
acting like PICK 1 now. These changes have made these functions faster, 
and better to use. Generating an error is considered something to 
do when it is really important, as it sometimes is. How important 
is the /skip < 1 error?

The problem is that DIFFERENCE/skip < 1 generates an error, and every 
other function /skip < 1 hangs. So the question is whether they should 
*all* be changed to act like MOVE (silently DWIM), or all be changed 
to act like DIFFERENCE (generate an error).

Steeve, the basic math operations generate new values, they don't 
modify in place. This cold cause a lot of memory overhead. Modifying 
operations might be better to do as functions, perhaps even native 
functions loaded in plugins.

OK - no problem to ping Carl about it, no? I think he just did not 
generate it yet ...

Part of the trick here is that you have to balance the benefits of 
error generation versus the overhead of error handling. We've been 
careful to make a lot of code that used to generate errors in R2 
just work in R3. If there is a good rationale for "just working" 
that is.

I'm not saying that unset! values in an ANY or ALL is one of those 
cases where there would be benefits, just that it might be. Benefits 
like being able to use functions like PRINT in ANY or ALL without 
having to do tricks like (print 'hello true). If errors would be 
more common than beneficial code, then generate errors.

BrianH: I won't be able to make an example (and maybe it's not possible 
now) .. but I was asking because of this maybe stupid idea for "poor 
mans continuations" 


that are built on top of language as a lib (because of rebol powerfull 
treatng of itself): 


- you have a function >>myfunc: func [ a /local b ] [ b: 5  return-cont 
 a + b ] <<
- at runtime when function is called you reach return-cont which:

  - you collect all it's local words and their values into a block 
  (with stack/args etc)  for example [ a 1 b 5  ]

  - you also get current position of a running block (already seems 
  to be possible with stack/block + next )  [ a + b ]

  - you generate a function at runtime that has >>does [a: 1 b: 5 a 
  + b ]<<
  - you return taht function as a normal return value.
this means that this would be possible:
>> cont: myfunc 5
... do some stuff
>> cont 
== 6

any thoughts :) ?

- you generate a function at runtime that has >>does [a: 1 b: 5 a 
+ b ]<<
That is the slow part, and for some code exponentially slow.

Yes But i'm afraid that twitter will generate a massive flow of messages 
after a while.
And even if you dont read them, you download them after each sync

why does DOing the exact same script, generate the proper error in 
the main app and generate a bogus error when DOne from a module... 
that is the problem.

I added a fairly comprehensive comment, with tests. I had to generate 
3 CureCode tickets as a result :(

I'm OK with declaring that bounds don't matter, and that INDEX? is 
not an error. The rationale for the new series bounds model was my 
idea, anyways. And having =, !=, == and !== (and their actions) not 
generate an error is consistent with that. Just taking the devil's 
advocate position :)

anyway, this is always a problem, when we try to generate numbers 
in an "exotic" interval, not in the usual [0.0 .. 1.0]

another variant would be to generate the uniform deviates in the 
definite interval not allowing multiplication to "mess things"

Now try assigning those opening and closing pieces to variables so 
as to generate code.  If you try to use Rebol then there is an immediate 
problem because a great deal of real world code uses quoted strings. 
 So now you need a literal string.  But in Rebol that will be in 
curly braces. Sunk.  Now you are escaping chartacters when you are 
tyring to generate code.  No problem if code genrated by Rebol is 
consuked by Rebol.  But that is not realistic.  So now you are generating 
code with Rebol but then preporcessing hte code with Perl to strip 
out the escaping carets on the ^{ and ^} ???

I am hoping this is on BrianH radar ...  I thought at one time you 
were kinda the guy who spoke for the community ?  Gab is aware of 
this and Oldes - doesn't he generate FLASH or PDF or something ? 
 At the moment my own option is to take shelter in PHP and PHPTemplate. 
 I wanted to fall back on Smalltalk but all the web frameworks from 
the MVC gurus seem to miss the point that the View was supposed to 
be de-coupled.  Go figure.

REBOL can generate JSON just fine, and there are no carets in the 
generated output.

RobertS, this means that you can do server-side processing of JavaScript 
using R3 right now, without heredocs. All you need to do is escape 
unbalanced { and } in your REBOL syntax { } delimited strings. The 
escaping is resolved at LOAD time, so the resulting strings don't 
have escape sequences in them. Then you can combine and generate 
the resulting string data without concerning yourself with escaping.

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

Just noticed something else interesting about PHP. I just tried to 
generate an exception by division by zero. No exception was thrown! 
Instead, the result of the above expression was a boolean, false.

You are right about a hex editor seeing the REBOL source though, 
unless you do something weird to generate the source instead of referencing 
a literal string. However, remember that the code in memory is the 
result of executing the code in the module source, generating the 
in-memory data. That generation can be really elaborate if you like.

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

Would be cool if REBOL interpreter could generate some form of symbol 
file for encapped scripts.

And given the ability to create REBOL code, you should be able to 
generate any datatype with a to-* function.

Pekr, the opposite of LOAD is MOLD/all, the opposite of DO is MOLD. 
MOLD doesn't generate serialized syntax.

No, LOAD doesn't execute code, and the point of MOLD is to generate 
executable code. LOAD/all does something different.

just to understand, you generate a file and u upload to googledocs, 
then requests it from google server?

so that is the rsp you request that generate the file and upload 
it to google

I tried using the pem file I can generate on stunnel page and I see 
that it's certs and privkey are half shorter... maybe I don't have 
tre right version type or something of encription setup?

doc has said that face prevents rebol apps running as windows services 
.. I didn't know that you could encap without face as cheyenne needs 
that to generate the captcha images ...

There's also now the ability to define a timer per socket application 
to generate server-side events (powered by my scheduler library).

do-task in this example, sends the raw incoming data from the browser 
to a worker process using ws.rsp script to generate a response that 
is sent back to the web socket app (if a /on-done callback has been 
defined) or directly to the client browser.

You would generate the timer events in the socket-app, pass the job 
to do to an RSP script, and use the /on-done handler to send the 
response to the client you want once the RSP script finished its 
work.


(this will work once I fix the issue with 'do-task calls from 'on-timer 
events).

Ah.. i figured out where Im lost!  It's at the "generate a timer 
event", "pass the job to an RSP script" and the "use the /on-done 
handler" bits :)

Graham, without money, it's just not worth it, you need a lot of 
libraries to make a programming language useful, no way one man only 
can build all the required ones...but if it can generate enough incomes, 
you can pay some developers for that.

looks hard to maintain.


In PHP, I process/generate all the hypertext, and avoid the 'dynamic' 
aspect of web page creation altogether, so my page templates look 
like so;

<html>
<head>
<?= $cssincludes ?> // CSS
<?= $headincludes?> // JQuery, specific javascript functions  
</head>
<body>
<?= $body ?>
</body>
</html>

re System logging service: it's not an option because :
- not a cross-platform solution

- some files *have* to be generated directly by Cheyenne (like the 
HTTP log file)

- the trace output in debug mode can generate huge entries that are 
inappropriate for syslog

- the trace output needs to be free from non-Cheyenne entries (or 
it might become unpractical to use for developers)

because the system actually self-identifies its available interface, 
we could even generate the SOAP xml schemas automatically, as in, 
totally dynamically.

I'm trying to generate an .rsp page based on a query string the way 
a cgi page does using 'decode-cgi system/options/cgi/query-string'

but it does not seem to be working. How is this sort of thing done 
with .rsp?

Regarding the new attached files feature: adding or deleting files 
doesn't generate any new entry in the ticket's log. As attached files 
management is done asynchronously, it doesn't require posting the 
ticket's form to commit changes. So, the policy for logging attached 
files actions is not clearly defined yet. Your feeback about this 
topic is welcome.

private$ ls

ChangeLog.txt     build-db.sql   generate-load.r  helper.r   instances
access-control.r  db-abstract.r  generate-test.r  install.r

I always thought that it was easier to write REBOL code than C code. 
Extension would require a C compiler that will generate an additional 
DLL (times the number of OS to support...). I looks to me more like 
a regression compared to R2 if /Library get trashed in R3 (unless 
someone provides a similar interfacing system). 


SWIG is huge compared to /Library. Having to provide the C header 
files is not always convenient compared to just declaring a routine! 
from online API documentations (like e.g. MSDN). I would prefer to 
keep having /Library in R3 for fast and handy OS interfacing, and 
the ability to build my own Extensions for cases where it's not enough.

that is a great idea... generate the intermediate C files, and convert 
them into rebol extensions... using only the top-level headers as 
what is exported as commands and defined structures.

You wouldn't need to package your generated code as an extension, 
just generate to memory and run it from there.

A command! is an indexed dispatch function, and the index has no 
inherent meaning. You could dynamically generate functions with libtcc, 
which would all have the same function signiature because they would 
just take command! call frames. These generated functions could be 
referenced from an array of function pointers. After you generate 
a new function and assign it to a new array slot, return the index 
of that slot to the calling REBOL code (embedded in the libtcc extension) 
and it can then make a command! with the libtcc extension's handle 
and that index. Then that command! can be called like any other REBOL 
function.


A trick though is that the generated C code would need to use the 
extension macros to manipulate the function arguments, rather than 
direct variable access. In other words, your generated functions 
would be extension-style code, not regular C code.

in the code... 


rsize: 3   is the record size...  like the /skip value in most series 
handlers  

my two funcs will adapt, since you provide it the record size


but ... ehehe, I just realized that find HAS the /skip attribute... 
doh!!! the above can be made MUCH faster still, especially by removing 
the need for the keys (which take a bit of time to generate on large 
lists).

I think, that it is quite natural. You should probably generate some 
random data having (approximately) similar properties as what you 
intend to process and try some variant approaches to really find 
out, which one is best for the task. Do you know, that it is possible 
to index just a specific record field, i.e. you don't need to make 
a hash containing all the data from the database?

Heck, 2.7.7 uses two functions that generate and run code at *runtime*: 
APPLY and MAP-EACH, both native in R3.

Yes you do, because the .rlp was used to generate the original .r, 
not the current fixed .r.

What is used to generate the .r from the .rlp ?

No, I mean how do you update the gui while in the middle of a network 
operation ?  The only way to force the gui to change is to generate 
a GUi event, like a mouse click etc but a fake event

One question I have that I did not see in reading all the docs .. 
how does one generate a GUI event ( to be used inside network code 
) ... since one can't use a wait to allow the gui to update?

Can we actually generate events?

there's no rate but you can generate time events aswell

ok, but even if you generate own events you need to WAIT at some 
point so the CPU is not at 100% no?

As I said the problem is not in the demo itselt...it is in the timing/loop 
code.

You can  easily to see it if you put some code(doesnt have to be 
related to draw or even graphics) in your small example you posted 
previously. You will see the same slowndown which means: don't put 
time consuming code into the AWAKE handler. But where to put it if 
you generate time events in that place? :)

Max, yes, we can add different emitters. It would even be possible 
to generate HTML out of a VID form.

Hosting Webkit wouldn't help here: The whole point to HTML5 etc. 
acceptance is that people don't have to install another program - 
they can just use their existing web browser. Hosting Webkit would 
only help us if we want to display existing web browser code; it 
wouldn't be necessary for generating code to run in Webkit, because 
the copy of Webkit that people would be displaying your GUI in would 
usually be a separate program, often on a separate computer. And 
HTML/JS/CSS is just text - we can generate text already.

AdrianS: as I said in my last message here, "-by default layout elements 
have to be organized either in PANEL or GROUP structures (though 
it is possible create your super special style for circular layouts 
or whatever ;))"

By this I meant there will be two default 'layout generator' styles 
GROUP and PANEL but you can create own styles that will generate 
their content differently.

sure, have you ever written a very large document in Word and then 
wanted to generate a table of contents using its built in TOC generator?

Many questions are put here unnecessarily by me. If app like deme/style 
browser would be working, I could see example usage, instead of looking 
into flattened source code. You live with the sources on daily basis, 
so you might understand, that I would like to help with testing, 
but without any instructions it just might generate many questions 
on my part. I might stop complaining about the look for now, but 
that's all I can save you from :-)

We are still buildin a bunch of infrastructure on our side, so that 
we can release stuff faster, know it will build for you, generate 
automatic change-logs etc.

I'm going to rephrase my idea: In general it could be possible to 
use blocks of blocks inside the layout. This would make it easier 
to generate layouts and not care about style argument lengths:

view [[button button] [field field]]


Of course you can't split a style in two blocks, but this wouldn't 
be needed anyway:

view [[button] [do [something]]]


This is similar to how gradients can be put in blocks inside DRAW. 
Is there anything that would conflict with that?

Henrik, good point. We need to consider "generate by script" in all 
dialects etc. IMO being able to use even more abstract descriptional 
approach and generate on the fly is a key pattern.

having written  a few, I recommend making it an external api which 
is fully "gui enabled"   this way, undo events can automatically 
call face accessors,  and you can put the undo stuff in the logic 
rather than the gui.   many times, the logic might generate a few 
undo, or none, based on things which the gui can't properly be aware.

At this point it would be easier to use R3 as a preprocessor to generate 
apps that are implemented in Java than it would be to use R3 directly.

actually i use current tasks to generate time events

Sunanda, you are ignoring context. None of those generate an error. 
It is the code surrounding that code that generates the error.

Wait, the THROW/break ones always generate an error. THROW doesn't 
have a /break refinement.

If the CGI data is parsed properly it should never generate anything 
other than pairs. If it ever generates chained assignments that is 
an error in your parse rules, not CONSTRUCT.

I expect that it is just some adhoc function that Carl rigged up 
in order to be able to generate the examples on the error pages.

DELECT could be used to convert a dialect block with unordered and/or 
parameters to commands into a command block with ordered, mandatory 
arguments. It does it already; all that would be necessary is to 
have if generate its results in a flat block rather than nested blocks. 
There would be no need to remove it - just change the output format.

Basing some REBOL-related tools on Silverlight and/or the DLR would 
be a plus. Keep in mind that we don't have to make the whole of REBOL 
run within the JVM or DLR - REBOL is great for making development 
tools, which can be used to generate Silverlight applications, just 
like they generate Flash applications. Or R3 could be used as a library 
by Java, or as a supplemental developemtn tool, or a code generator, 
whatever. Remember, most of REBOL is a set of awesome libraries and 
dialects. REBOL without most of DO or AGG is still useful.

R3 is best as its own thing. But it can be used to supplement applications 
in other languages, like Lua. Or it can be used to generate applications 
for other platforms, as a development tool.

yes, but network schemes are done on top of the framework itself. 
Adding them, does not influence the Core itself, while I fear, that 
not having tasking in the beta, could also mean, that later on it 
migh generate the need to change our code ...

I don't like issues as words. The advantage of  faster acces to #include, 
that is only used one time at startup or even less when encapping 
does not outweight  that I shall no longer generate large numbers 
of issues, but instead strings or binaries for lists.

so for example, if an application halts due to an error... the stack 
is effectively empty, since its back to the command-line.  :-(

ex:  I added a voluntary 0 / 0 to generate an error.

liquid/add[3]/instigate() [
** Math error: attempt to divide by zero
** Where: / unless cleanup switch foreach either if insti
** Near: / 0 plug/dirty?: plug/valve/purify plug if all [
    plug/re...

>> stack 10
== none

can someone please tell me how we can generate errors in R3.  cause-error 
has no list of appropriate values and everytime I've tried to use 
it it just fails with "you have no clue" errors.

Thanks, Ladislav.

There are several anomalies, which at least could be noted in the 
documentation under the pair! data type.


Another [anomaly]/[undocumented change from R2 behaviour] is when 
a pair overflows:

....R2 throws an error, or replacee the large number with 0 (itself 
an odd behaviour).

....R3 can generate +/-infinity. As far as I know this is the only 
way in R3 to get a -/-INF; and the value is not usably serialisable:
    xx: as-pair -1e44 1e44
    == -1.#INFx1.#INF
    type? first xx
    == decimal!
    load mold first xx
    ** Syntax error: invalid "integer" -- "-1.#INF"

That last trick would be difficult to do safely though, at least 
as FUNCT is used in the mezzanine generation process. Mezzanines 
are generated with FUNCT but saved with MOLD into the form where 
they will be loaded at runtime. This means that FUNCT can't generate 
code that has inline function or datatype values in it, since they 
won't mold properly. Unless you inline the references to ASSERT and 
NONE!, those words couldn't be used as function parameters or local 
variables in the generated functions. Tradeoffs, I guess.

In theory, you could generate R3 scripts using R2 and still have 
most of the same features. Loading them would be trickier though.

So a good way could be to generate a R3 C based extension wrapper 
around the R2 used function and use the R3 extension interface. It's 
much better and simpler to use.

I presume the idea of this is to easily generate javascript and the 
like

#[[Graham

I presume the idea of this is to easily generate javascript and the 
like¨
Graham]] - I presume, that I wrote above, that this is not true

I was on the fence about the heredoc proposal, but now that Ladislav 
has come up with a syntax that makes sense (this was missing from 
the previous proposal) I am now all for it. One caveat though: It 
would be best if, like other string syntaxes, the syntax details 
are thrown away after loading. By this I mean that
a
{a}
#[[blah
a
blah]]

should all generate the same string. Once it is loaded, there should 
be no way to determine that it was specified as a heredoc. Heredoc 
should be syntax only, not in any way affect semantics.

there is probably a better method than the one I use to generate 
the permutations

I have to generate all the possible combinations of each drug id 
with all the others but not with those in the same set

so at present I think I generate all possible combinations and check 
to see if they're in the same set and if not do the sql query