AltME groups: search

LOL, I was just posting a rant on FB that can be summed up as "if 
you do it over and over again, make a BLOODY shortcut".

As to notes about HEAD, I realize now that I confused INSERT and 
APPEND

 - APPEND used in a similar way as above would not need HEAD either

Having a series with index 1 (the head has this index), neither INSERT 
nor APPEND can change the index of the series. What they do is something 
else - they return a series with a different index.

To illustrate this further, let's consider a trivial example:

    a: 1
    b: 2

    add a b ; == 2


You can examine A and B now and see that the ADD function did not 
change A or B, but it returned 2 (another value). Similarly, INSERT 
does modify the argument series, but not its index, however it returns 
a series with a different index.

>> add: :multiply
>> a: 1
== 1
>> b: 2
== 2
>> add a b
== 2

You can always find a solution :-)

/LAST refinement doesn't return the last match when used with /REVERSE 
refinement. Is that a known issue?

>> FIND/reverse/last tail "aoboco" "o"
== "o"
>> FIND/reverse tail "aoboco" "o"
== "o"

>> FIND "aoboco" "o"
== "oboco"
>> FIND/last "aoboco" "o"
== "o"

Your example should be 

== 3" I guess?" - actually, I had a: 1 and b: 1 originally, and I 
somehow "managed" to change B to 2 :-(

If I remember correctly, you can't go 1 to 1 from xml to object. 
You can to block.


I've only used my xml2rebxml.r, which produces a block. You could 
work from there, pull out the elements, you need, and produce an 
object.
http://www.rebol.org/view-script.r?script=xml2rebxml.r

Endo, that's just his notation for a text node - not meant to imply 
it's a file.

I see, I just confused if it's a bug or not.
>> load-xml {<a>test</a>}  ; == [ <a> "test" ]

>> load-xml {<a b="c">test</a>}   ; == [ <a> [ #b "c" %.txt "test" 
] ]

Why this doesn't work?
>> parse [1] [1] ;== false

while this one works
>> parse [a] ['a] ; == true

So, no chance to specify an exact number in a parse rule?

parse-int-values: func [

    "Parses and returns integer values, each <n> chars long in a string."
    input [any-string!]

    spec [block!] "Dialected block of commands: <n>, skip <n>, done, 
    char, or string"
    /local
        gen'd-rules ; generated rules
        result      ; what we return to the caller

        emit emit-data-rule emit-skip-rule emit-literal-rule emit-data
        digit= n= literal=
        int-rule= skip-rule= literal-rule= done= build-rule=
        data-rule skip-rule
][

    ; This is where we put the rules we build; our gernated parse rules.
    gen'd-rules: copy []
    ; This is where we put the integer results
    result: copy []

    ; helper functions

    emit: func [rule n] [append gen'd-rules replace copy rule 'n n]
    emit-data-rule: func [n] [emit data-rule n]
    emit-skip-rule: func [n] [emit skip-rule n]
    emit-literal-rule: func [value] [append gen'd-rules value]
    emit-data: does [append result to integer! =chars]

    ; Rule templates; used to generate rules

    ;data-rule: [copy =chars n digit= (append result to integer! =chars)]
    data-rule: [copy =chars n digit= (emit-data)]
    skip-rule: [n skip]

    ; helper parse rules
	digit=: charset [#"0" - #"9"]
    n=: [set n integer!]
    literal=: [set lit-val [char! | any-string!]]

    ; Rule generation helper parse rules
    int-rule=: [n= (emit-data-rule n)]
    skip-rule=: ['skip n= (emit-skip-rule n)]
    literal-rule=: [literal= (emit-literal-rule lit-val)]
    done=: ['done (append gen'd-rules [to end])]

    ; This generates the parse rules used against the input

    build-rule=: [some [skip-rule= | int-rule= | literal-rule=] opt done=]


    ; We parse the spec they give us, and use that to generate the

    ; parse rules used against the actual input. If the spec parse

    ; fails, we return none (maybe we should throw an error though);

    ; if the data parse fails, we return false; otherwise they get
    ; back a block of integers. Have to decide what to do if they
    ; give us negative numbers as well.
    either parse spec build-rule= [
        either parse input gen'd-rules [result] [false]
    ] [none]
]

Just as an example of how you can work around it with a bit of indirection.

this is on r3
am trying to do a simple 
read http://google.com
and get 

Access error: protocol error: "Redirect to other host - requires 
custom handling."
how do i custom handle?

Basically the http protocol sees a redirect eg. from http:// google 
to https google and complains.

any ideas why? i'm on a amazon linux instance...

i think so graham - did a yum install curl

In Rebol, there is no "pointer" (C like).

string!, binary! are series. Series are groups of elements (character, 
octet) so a word! (like str or end) associated to a serie hold also 
a position on it.

str: "abcdef"

==> Create a string! in memory, put "abcdef" as its content, create 
a word! 'str an make it point to its head.

hmm, I just tried for i 1 str 1, and it screams ... but maybe if 
given the same type, a string for e.g., maybe it takes their index 
value?

you should know, that 'end is just a reference to still the same 
str, which can be proven, by inserting new element into str ....

end: find str "d"

==> search for "d" in the "abcdef" series in memory, then create 
a word! 'end that hold the position of "d" in this same serie.

so 'str and 'end just hold different position in a unique string!

Then, the 'for loop can work as it's positions in a unique serie!

Kees - beware - rebol series concept needs really carefull aproach 
- it caused me a headache when working with series, till I became 
accustomed to it. And still, sometimes, I use trial and error aproach 
in console ...

Kees - better start with a fresh session, fresh series ....

If I replace the text in str, end still equals to 
def", so it does not point
at str any more."
How do you replace the text in 'str ?

If it's like this:
	str: "new text"

then you have created a new string! in memory and point 'str to this 
new serie. 'str and 'end does not point anymore the same string!

to change the content of the "abcdef" string! you create in first 
place you have to change it in some way.
Pekr used 'insert to add a character in the begining.
You can change all its content like this:
	insert clear str "new content"
then
	probe end
give
	" content"
So we have acted on the same string in memory.

The key with series programming in Rebol is always "Is this the same 
serie or a new one ?"
Sometimes you want to act on the same.
sometimes you want to act on another.
FUNDAMENTAL

#[[DIdeC
str: "abcdef"

==> Create a string! in memory, put "abcdef" as its content, create 
a word! 'str an make it point to its head.
]]


- that is not true, in fact. The proper description is as follows:

    str: "abcdef"


is a Rebol source (or a part of it). That source is first processed 
by LOAD. LOAD creates the Rebol value representing "abcdef". Also, 
LOAD does *not* set the 'str value (yet).


Later on, when the DO function evaluates the (already LOAD-ed code), 
it just makes the 'str variable to refer to the string value not 
creating anything at all (this difference is crucial).

There is even a possibility to write:

    end: #[string! "abcdef" 4]

I can give you a similar description as above even for this case, 
if you like.

Ladislav: "this difference is crucial" Could you please explain why 
this difference is important? Or better why it is important to understand?

I understand there is a big difference, but why it is important to 
know?

I have a question about timezones. I need to make a selector for 
workonomic where user can set the TimeZone Like "Europe/Ljubljana" 
 instead of TZ offset which changes between summer/winter time depending 
on the timezone etc..

I assume rebol doesn't have "Labeled Timezon => current offset" capability 
so I am wondering if anybody had to do this and what (s)he found 
the best solution was? I see two ways, using external service in 
a lang that has such database/library (like php's ) or using the 
OS below (from bash) "TZ=":Pacific/Auckland" ; date +%z" ... also 
is there anything still I can do inside rebol, like getting some 
prefilled sqlite db using some lib I don't know of..

Yes, it's in Qtask source. I used a script to translate the TZ database 
to REBOL, then made a REBOL function to convert between timezones.


Note, if you are using MySQL, you can have it handle timezone conversions 
too.

Thanks Gabriele, I found by googling that mysql can have timezone 
database installed and has the functions to handle it then. http://stackoverflow.com/questions/805538/in-mysql-caculating-offset-for-a-time-zone
(the second answer, with a link of how to install if anyone else 
will be looking)

You have a better chance of me seeing such a question if you pose 
it in !R3 Extensions

yes, I see. parameterized inserts are ok but perhaps better make 
a rejoin.

TomBon, don't encourage people to use rejoin for SQL queries. Definitely 
use parameterized queries. Building your own queries with rejoin 
is a sure recipe for SQL injection.

i suggest to get the html+cgi echoing working first, then getting 
a minimal script that inserts a value into your database working, 
and then putting the two pieces together by extending your "echo" 
cgi to insert into the database

checking for proper values and a corerct sql syntax should be always 
done even when parameterized.

Nice to hear, TomBon. Nonetheless, such checking is exactly what 
parameterized queries do, and I often have to fix errors made by 
other developers who don't use them. Plus, parameterized queries 
are a lot quicker on most databases because the query plan gets cached.

It is always a bad idea to suggest to newbie programmers that they 
not use parameterized queries.

guys ...i am happy :) it is working... tnx a lot  Andreas ...

isn't this execution optimation?. in this case a stored procedure 
will help also. how will this prevent from sql injection? compared 
to a concatenated server side sql string?

If you build a query dynamically with rejoin or something, the query 
is put together client side and then the server has to generate a 
new query plan for each distinct set of parameter values. This takes 
time and blows the query plan cache, which slows down the whole query 
process.

The problem is that your ad-hoc parameter screening is usually not 
perfect. Parameterized queries don't build a query in the server, 
they just plug in the values to an already-compiled query (the "query 
plan"). The server doesn't have to do any parameter screening other 
than for malformed values in the protocol.

For new developers ad-hoc parameter screening is even more likely 
to be bad (and most that don't use parameterized queries are still 
new, no matter how long they've been programming, because parameterized 
queries are almost always inherently better). Even if it wasn't a 
safety issue, they're a lot faster.

About parametrized queries: The only problem using them on R2, at 
least with RT's default ODBC, there is no chance to use NULL values. 
None of those work:
insert db-port ["INSERT t (a) VALUES (?)" NULL]
insert db-port ["INSERT t (a) VALUES (?)" 'NULL]
insert db-port ["INSERT t (a) VALUES (?)" "NULL"]
insert db-port ["INSERT t (a) VALUES (?)" none]
insert db-port reduce ["INSERT t (a) VALUES (?)" none]

you have more than one solution, the first is a simple serial SELECT 
on each table -> compare the output for equal.

of course this produce unnecessary DB overhead but I guess you won't 
feel any speed difference except you are

serving a whole city concurrently. another, better one is a JOIN 
or UNION.

SELECT table_name1.column_name(s), ...
FROM table_name1
LEFT JOIN table_name2
ON table_name1.column_name=table_name2.column_name


the JOIN direction (LEFT,RIGHT,INNER) for your reference table is 
important here. 

the resultset is a table containing BOTH columns. if both having 
a value -> match, if one is empty then you don't.


index both fields to accelerate the query and use something like 
the free SQLyog 
to test different queries to make debugging easier for you.


while you situation reminds me to myself, sitting infront of a monochrom 
asthon tate dot some decades ago

and asking what next?, you should 'bite' yourself now thru the rest. 
It won't help you on longterm if you don't.

@TomBon: my query for joining two tables is :insert db["select * 
from data LEFT JOIN data1 ON data.oneone=data1.oneone"]     and output 
is :[

    ["c" "a" "t" "a" "e" "r" "o" "a" none none none none none none none 
    none]

]    plz tell me what should i write in query that i get values instead 
of none in output ?

the output of this query insert db[{select * from data LEFT JOIN 
data1 ON data.oneone=data1.oneone}]
 is : [

    ["c" "a" "t" "a" "e" "r" "o" "a" "c" "a" "t" "a" "e" "r" "o" "a"]
]

i got this results:c c
a none
t t
a none
e none
r none
o none
a none

a quick update on elasticsearch.

Currently I have reached 2TB datasize (~85M documents) on a single 
node.

Queries now starting to slow down but the system is very stable even 
under

heavy load. While queries in average took between 50-250ms against 
a 

dataset around 1TB the same queries are now in a range between 900-1500 
ms.

The average allocated java heap is around 9GB which is nearly 100% 
of the
max heap size by a 15 shards and 0 replicas setting.

elasticsearch looks like a very good candidate for handling big data 
with 

a need for 'near realtime' analysis. Classical RDBMS like mysql and 
postgresql

where grilled at around 150-500GB. Another tested candidate was MongoDB

which was great too but since it stores all metadata and fields uncompressed

the waste of diskspace was ridiculous high. Furthermore query execution 
times 
differs unexpectable without any known reason by factor 3.

Tokyo Cabinet started fine but around 1TB I have noticed file integrity 
problems

which leads into endless restoring/repairing procedures. Adding sharding 
logic

by coding an additional layer wasn't very motivating but could solve 
this issue.

Within the next six months the datasize should reached the 100TB 
mark. 

Would be interesting to see how elasticsearch will scale and how 
many
nodes are nessesary to handle this efficiently.

I have a problem with RebDB: how works db-select/group?
Example:

>> db-select/where/group/count [ID title post date]  archive  [find 
post "t" ] [ID]
** User Error: Invalid number of group by columns
** Near: to error! :value

I would like to be able to include other columns in the output that 
are not part of the grouping or count, but I haven't figured out 
how to do this in RebDB.  I have used a parse grammar on the output 
to achieve the desired result.

I would also like to query the results of a query, which I haven't 
figured out how to do so without creating and committing a new database. 
 So I have  used a parse grammar to merge two queries.

SQLite version 4 announced/proposed. The default built-in storage 
engine is a log-structured merge database instead of B-tree in SQlite3. 
As far as I understand the docs This store could be usable standalone 
or use SQL frontend. Google to SQLite4.

Endo as I wrote google for SQLite4. direct link is: http://sqlite.org/src4/doc/trunk/www/design.wiki.
There is a mirror of souces at https://github.com/jarredholman/sqlite4
also.

I've also had loading problems with R3 extensions on Linux that worked 
before. Sometimes you seem to need an older R3, sometimes a newer

Yes, it's in progress. Some like SQLite are one-to-one in Red like 
in Red/System. SDL is used more as a part in other low level bindings, 
such as OpenGL. OpenGL itself is waiting for floats in Red

ok, so got valid ODBC connection string fro .xlsx files. R2 crashes 
when copying a data though ...

p: open [
     scheme: 'ODBC

     target: "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=C:\Work\sales.xlsx;"
]

R3 extension will open the door to many usefull extensions now. We 
should collect the current status of existing extensions and of course
new ones we like to see. 
Quick check on current extensions (lib based) :
cURL, ZMQ, ODBC, FMOD, IMagick...


Another area is what is the best practice to create and maintain 
embedded extensions, how to integrate a dynamic built for this how 
to organize the source tree.

Currently I am working on a embedded cgi extension as a testcase, 
this will lead also into questions like: mezz or native, embedded 
or lib?

Extensions on my list:
CGI, JSON, POSIX, PCRE and some math libs.

If you have a request that R3 be ported to another platform, here's 
the place for it. You might want to keep in mind that iOS and Android 
have their own groups, but if you just want to get it to compile 
on their respective SDKs then this is the place :)

Android and iOS.  How much of a bounty do I need to offer for R3 
with GUI on Android?

That's a huge amount of work

I'm not particularly interested in it, except maybe as an extension 
of a Red/System port

NickA: during my private talks to Cyphre, he told me that if he would 
aproach the View engine nowadays, he would abstract it a bit, so 
that it could use various rendering backends - AGG, Cairo, so that 
where platform permits, it could be HW accelerated. But - such project 
would take some time, and Cyphre would have to be sponsored, in order 
to be able to do the work. I think, that it could be even written 
in a way, so that both R3 and Red benefit. But who knows ...


As for Red - no party is willing to port View engine, yet :-) Doc 
wants to aproach it other way - to use something like VID dialect, 
but final toolkit used would be the native platform one. Kaj did 
some example with Red/System + GTK, if I understand it correctly. 
I still think that even for Red, something like small View  engine 
would be benefical, e.g. for embedded work, where non traditional 
graphics is not a problem.


Dunno, how difficult would it be to get View sources adapted to Red/System. 
Red is missing on timers, events, etc., so maybe later, so that it 
can be naturally plugged in to its architecture ...

Thanks Pekr.  I spoke with Cyphre too - waiting to here if he's interested 
in being sponsored, and how much it would cost to make Android a 
priority.

Btw.. with High Resolution Displays coming these days, the HW powered 
GUI is a must. The CPU rendering will be just for making high quality 
assets for GPU. http://www.tomshardware.com/news/Intel-Higher-Resolution-Displays-Coming,15329.html

From http://www.rebol.com/cgi-bin/blog.r?view=0519#comments


To download a tarball of an executable REBOL 3.0 program for the 
Raspberry PI (build with Raspbian “wheezy” ) take a look at:

http://www.TGD-Consulting.de/REBOL/r3-RPi.tar

---


pi(at)raspberrypi ~/dev/r $ uname -a Linux raspberrypi 3.2.27+ #250 
PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux

pi(at)raspberrypi ~/dev/r $ ./r3

>> system/version

== 2.101.0.4.10

>> system/build

== 16-Dec-2012/13:13:11

>> system/product

== core

With HRD comes higher performant GPUs but I'm not sure how CPU scales. 
Look at Adobe, they are almost dropping support for classic display 
list (rendered on CPU) and forcing everybody to use their Stage3D 
which uses GPU. It's not easy move as there is almost no tooling 
yet, but it's a must. CPU is not able to process so many pixels with 
the new screens (with high frame rate). I don't say we should drop 
AGG support, just that there must come GPU support using OpenGL/DirectX 
and let the AGG to do high quality rendering of assets.

Actually, Oldes, that's a great idea!  R3's new GUI could be built 
to utilize OpenGL by default.  That way, the GPU would handle all 
the graphics calls, and R3 would have 3D capabilities built-in as 
a bonus!  This would probably even make porting to Android and other 
platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?

It is. OpenGL ES2.0. As well as Android. Actually I don't think there 
is a chance to do GUI on these platforms without OpenGL.

We did a short test some time ago to use OpenGL, works but is quite 
some work to implement it completely.

MaxV, I made a couple tiny edits to clarify https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw
.  I hope that's ok.

Couldn't DRAW work the same way as it does now, but render to a bitmap? 
 Then that bitmap could be rendered by OpenGL like it does any other 
bitmaps.

I believe the Android porting effort will show us what is the optimal 
solution. It is good to find a balance between highly optimized but 
not much compatible HW engine and smoething that is fast enough and 
can be ported without big pain.

Just think, though, if OpenGL was the default renderer for graphics 
in R3, you could create a flat surface for a 2D screen, but during 
the same session, you could create another flat surface for another 
2D screen at a 90% Z-axis orientation to the first, and then rotate 
from the first 2D screen to the next 2D screen in a fluid 3D way.

I did quite a few tests with OpenGL on R2, but the killer for me 
was the inherent delay with R2 calling the methods (functions) in 
the OpenGL dll.  I was still able to rotate an object created with 
over 1000 coordinate points 30 times per second on a quad-core computer, 
but that's probably 1000 times slower than you could do it with straight 
C on the same computer.

I toyed with the idea of writing a C-based dll that could take all 
the information for rendering an entire data structure from R2 so 
R2 would only have to make one method call to a dll per frame instead 
of thousands, but couldn't get enough higher priority items off my 
list to get started on it.

There are plenty of possibilities here. 

Either port VID and have to deal with it's flaws and the history 
with it
or go the path of the RebGUI
or redo VID 

I have read somewhere that Carl expected someone to come up with 
something better than VID. 

I like VID yet it has its oddities, like when positioning elements 
using 'at. It could be improved in some of its behaviours, if you 
import it you may be hindered by this aspect, and it may get harder 
than restarting with a restricted base set of widgets.

I don't think we're really out of topic here as the graphics stuff 
pertains to porting to different platforms, but if you wish, we could 
move this to the View/VID group.


When Carl was developing VID, he clearly expected that VID would 
not become the de-facto standard for Rebol graphics.  The face engine 
was the de-facto standard, and VID was simply one of what he expected 
to be several dialects for the face engine.  There were a few others, 
like GLASS, that came about.

We made it to compile R3 into a single EXE. Filesize:  855566  can 
be packed with UPX down to 368654   (43.09%) That's the base we use 
for encapping R3 apps into a single EXE.

Cyphre, thanks for that info.  So does the R3GUI framework work on 
all current R3 platforms?  I understand Android is a no, but everything 
else?

Don't know what the effort to get something going would entail as 
a regular plugin, but maybe as a Chrome Native Client there could 
at least be something available for Chrome more easily. It seems 
less work, at first glance.

https://developers.google.com/native-client/

I believe in order to do the browser port properly, the R3 engine 
would have to be multi-threaded or it would only work in one browser 
window. That seems like it would require a lot of rewriting if it 
isn't already in the design.

R3 is designed to be able to be thread safe. Whether it actually 
is that currently is a different matter

There's unfinished multitasking functionality in R3. It couldn't 
work if it would be impossible to use R3's internals in a thread-safe 
way. Indeed, the way functions work was redesigned to make it so

Hi, I'm reading the REBOL3's source codes, and I don't know It's 
a typo or not: in this file https://github.com/rebol/r3/blob/master/src/include/reb-c.h
at line 61, about defining the uint type, It seems #ifdef DEF_UINT 
 was not correct. Maybe #ifndef DEF_UINT ?

Can rebol be built to include .r scripts for a portable rebol?

Bundle scripts along with the rebol executable, for distribution, 
as a single file.

the console is just a loop in the main which gets a string and executes 
it.  what you'd do is execute a string of utf8 text directly.

I had the r3 hostkit running as a dll with full host support... in 
fact, I was able to execute R3 scripts from within R2   :-)

for embedded modules, it could be as simple as dropping your module 
in src/mezz/, including its filename in src/mezz/boot-files.r and 
doing a full rebuild (including `prep`) after that. didn't try yet, 
though.

Just so happens that I have a CB project file for the official source 
layout, if you want it. There's also a little change to make-make.r 
that you'll need t make for which he's made a pull request.

https://github.com/rebol/r3/pull/77

for which he's made a pull request
 -> "for which Andreas has made a pull request"