World: r3wp
[!REBOL3 Schemes] Implementors guide
older | first |
BrianH 28-Nov-2011 [2312x2] | Has anyone made an R3 scheme for testing? I mean a scheme that implements every possible port action, but just logs the values passed in. I want to get a better idea about how refinements are passed in to non-native schemes, if there are any potential security holes, etc. |
This would help with people trying to implement the R3 port model on any of the REBOL spinoff languages, by comparing the results. | |
Steeve 28-Nov-2011 [2314] | I've done some years ago, let me check :) |
BrianH 28-Nov-2011 [2315] | Hopefully after /string and such were added to READ :( |
Steeve 28-Nov-2011 [2316x2] | my infamous "virtual block" scheme. https://sites.google.com/site/rebolish/Home/idx.r?attredirects=0&d=1 |
Don't know if it still works | |
BrianH 28-Nov-2011 [2318] | Infamous indeed :) |
Steeve 28-Nov-2011 [2319] | Some frenglish comment inside. Should help |
BrianH 28-Nov-2011 [2320x2] | I'm working on an R3-style odbc scheme, but the tricky part is figuring out how to make it behave in the best R3 style. |
Quick poll: Should READ of an odbc port return flat data, and READ/lines return nested blocks? I know it's the opposite of how it was in R2, but since we don't have READ/custom we have to make do with what we have. For WRITE/lines I've been leaning towards bulk inserts. | |
Steeve 28-Nov-2011 [2322] | see if you can use COPY , COPY/part , COPY/deep as an alternative for READ |
BrianH 28-Nov-2011 [2323x2] | This scheme is not doing the R2-style two level db, dbconnection scheme, it's doing the one-level R3 style with the db connection being internal. COPY of a port copies the port itself, returning a new connection to the same database. COPY/part returns n new connections. The R3 style uses READ and WRITE, not COPY and INSERT. |
However, if you do FIRST of an R3-style dbconnection port, I was going to return a R2-style dbconnection port, or at least something that acts like one (in particular, it will act like ChristianE's odbc scheme). You should be able to use R2-style odbc code without change. | |
Steeve 28-Nov-2011 [2325x2] | I don't agree, you can redefine the meaning of any native which supports port! as parameter. See my v-block scheme. R3 don't constrain the semantic of your scheme |
there's no r3-style scheme IMHO | |
BrianH 28-Nov-2011 [2327x3] | The advantage of this is that you should be able to do really simple shortcuts for some operations. R2-style: db: open odbc://server dbc: first db insert dbc "select * from catalog.schema.object" copy dbc R3 style: read/lines odbc://server/catalog.schema.object |
Plus, with R3-style you could write asynchronous stuff that the R2 style doesn't do. | |
Your rejection of R3 style is what your block scheme infamous, and fun too :) | |
Steeve 28-Nov-2011 [2330] | the asyncrhonous stuff is doable only if one start GUI do-event loop. Quite limited |
BrianH 28-Nov-2011 [2331x3] | Not the GUI event loop, the event loop. Which is as simple as WAIT port. |
Your block scheme probably wouldn't have benefited from asynchronicity that much. Or would it have? That would be interesting to find out. | |
Async was pretty limited in R2 because you had to start the GUI event loop, which only the View builds had. With R3, even core has an event loop, and a lot of stuff uses it. | |
Steeve 28-Nov-2011 [2334] | My scheme only open regular files (not a messaging pipe) |
BrianH 28-Nov-2011 [2335x2] | It would be interesting to see if there would be a way to make an async file scheme using the async or non-blocking file APIs of various operating systems. This would be needed to support WinRT-based applications for Windows 8, for instance. |
I'm sure Linux, Mac and such have non-blocking I/O APIs too. | |
Steeve 28-Nov-2011 [2337x3] | I think R3 is too slow to benefit of such non blocking API. |
It makes sense wh | |
It makes sense when dealing with network connections but not with the file system IMHO | |
BrianH 28-Nov-2011 [2340x2] | It makes sense for Node.js, and would make sense for other compiled languages like Red and World. I suppose Topaz could build an R3-style port model on top of Node.js as well. |
Disk I/O pauses are becoming something that people complain about, like GC pauses. Only if it's faster or easier to use though. | |
Steeve 28-Nov-2011 [2342x3] | in R3, I noticed yh |
In R3, I noticed that the GC combined with the BALLAST option can erase the pause syndrom | |
It increase the GC refreshing rate and makes the pauses shorter | |
BrianH 28-Nov-2011 [2345x3] | Nice. I meant industry-wide, but it's good to hear that there's help for R3. |
Following the Win8 announcements, one of the interesting things is that WinRT, the new runtime, doesn't have blocking APIs. Only async. | |
File I/O can be pretty slow in some cases nowadays, particularly for accessing SD cards. I get freezes with AltME pretty often because of it waiting for blocking calls. | |
Steeve 28-Nov-2011 [2348] | Not only that, Altme has lot of rooms for speed improvements :) |
Maxim 22-Dec-2011 [2349x2] | funny thing is that single most effective way to increase disk I/O on windows 7 is to make all transfers non Async :-) |
it has been reported as being as much as 50% faster though all the explorer reporting becomes totally wrong... i.e. instead of wasting time trying to determine how fast and how much time it takes, it just does its copy and reporting is completely off, but its actually much faster. | |
Kaj 23-Dec-2011 [2351:last] | Sounds like a trade-off between throughput and responsiveness |
older | first |