Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Profiling Rebol API to DyBASE

From: knizhnik:garret:ru at: 22-Dec-2003 0:32

Hello Robert, I have released new version of DyBASE (0.16 ). Graham Chiu implemented in Rebol program which used DyBASE to store extracted mails from the server. It detects one problem in DyBASE related with storing large strings. That is why I have to release new version. It also includes new version of Rebol API: - generic index factory implemented by Gregg Irwin - I made all methods from persistent external functions. So now nstead of doing "obj/modify" you should use "modify obj". The name of all methods is preserved, except "load" method which is removed to load-persistent (to avoid conflict with system function). I hope that other methods (store, modify, deallocate,...) will not cause conflicts. In future if Rebol will provide efficient mechanism for methods, I return these methods back to persistent class. And right now it allows to reduce overhead of object prototyping and save a lot of memory. Now it is programmers choice whether to use object methods, external functions or use special class with method definitions. Also I have updated comparison table using as reference system my home computer. Result are different but in general ration of performance of different languages is the same. Sunday, December 21, 2003, 4:41:53 PM, you wrote: RMM> On Sat, 20 Dec 2003 21:16:01 +0300, Konstantin Knizhnik RMM> <[knizhnik--garret--ru]> wrote:
>> I thought, that once objet is created using prototype object, the >> values of prototype object fields are just copied to the new objects >> (doesn't matter whether them are scalars, series or functions). >> In this case there will be only one instance of the function compiled >> and bounded only once. But looks like it is not the case.
RMM> Hi, that's the difference in Rebol. It's not an OO language and it's RMM> object! datatype isn't OO related. Every word carries its own context. RMM> That's why you get the same words bound to different (new) contexts each RMM> time. The solution is to move the functions out of the context.
>> Rebol objects fits in this model (the only problem is that there are >> no classes, so I will have to make programmer to specify prototype >> object for the class). But if we provide persistency not for objects, >> but for blocks, then it is not clear to me how to store them. >> There will be no field names (but will be "hidden" fields, like >> current position name in variables referencing series).
RMM> Here is a rough sketch of an idea: RMM> A database could look like this: RMM> mydb: [ data [...] indices [...] db-meta-data [...]] RMM> Making blocks persisten will add an OID and a block reference to mybd/data RMM> as name/value pairs RMM> mydb: [ data [OID1 mydata1] ...] RMM> To index data there are serveral ways: 1) let the programmer add the RMM> fileds and the DB only maintains the mapping value/OID or 2) I'm RMM> registering which fields should be indexed. RMM> mydb: [ to-index [name street city ...] ...] RMM> The make-persisten function will look into mydb/to-index and check if the RMM> block-to-be-made-persisten contains any of the listed fields. If so it RMM> takes the value and the new OID and build the index. RMM> IMO the Rebol way to persistence is to dissolve that we need a fixed RMM> object structure. What we need is a lookup mechanism to answer things RMM> like: Give me all blocks that contain a 'name field that has a value in RMM> the range from A to B. What kind of blocks the result will be doesn't RMM> matter to the DB. The programmer needs to be aware to structure this. RMM> For example: I can add an internal field to my blocks to specify a class. RMM> What I'm going to do with this information is up to me and my program. RMM> mydata1: [_class address/germany name "" street "" city "" zip ""] RMM> mydata2: [_class address/usa ...] RMM> Both can have different field sets but the overall semantics is an RMM> 'address to my program. RMM> I hope you got the idea.
>> So it is possible to write normal serialization mechanism for Rebol >> (one that will preserve relations between objects), and even create >> database, which allows not only load/store, but also change/retrieve >> the data.
RMM> That sounds good to me! It should (in the first run) only be a persistent RMM> storage.
>> But it could not be done within DyBASE object model.
RMM> That's a pitty. I looked at DyBASE because it's intended for scripting RMM> lanugages and I though maybe it fits the Rebol world.
>> First task is significantly simpler, and if such module will be really >> interesting to many Rebol users, I can try to develop one.
RMM> I vote for it! We than can see how far we can go and what features need to RMM> be added to the persistens engine or to the Rebol code side. What do you RMM> think? RMM> -- RMM> Robert M. Münch RMM> Management & IT Freelancer RMM> Mobile: +49 (177) 245 2802 RMM> -- Best regards, Konstantin mailto:[knizhnik--garret--ru]