From sunshine at public.kherson.ua Thu Mar 4 00:05:05 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 3 16:05:11 2004 Subject: [Valentina-beta] Success on the MAC! Message-ID: Hi guys! Today I have run practically all our tests on MAC in CARBON target!!! This is the first so big run after we have switch to ICU. This is big victory!!! :-))) >From 7850 tests fails 116 On Windows 85. I should say that CW MAC show some errors/bugs that CW WIN do not show. Later we need resolve this. Null Threads crashes also btw. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From giv at tlc.kherson.ua Thu Mar 4 00:52:29 2004 From: giv at tlc.kherson.ua (Igor Gomon) Date: Wed Mar 3 16:52:57 2004 Subject: [Valentina-beta] Success on the MAC! References: Message-ID: <002201c40172$45e28870$761026c3@giv> > Hi guys! Hi Ruslan, > Today I have run practically all our tests on MAC in CARBON target!!! > This is the first so big run after we have switch to ICU. > This is big victory!!! :-))) > > >From 7850 tests fails 116 > On Windows 85. Congratulations! > I should say that CW MAC show some errors/bugs that CW WIN do not show. > Later we need resolve this. > > Null Threads crashes also btw. It's interesting, what? (Or maybe we discuss this in detail later?...) -- Best regards, Igor Gomon ------------------------------------------------------------- e-mail: giv@tlc.kherson.ua web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://listserv.macserve.net/mailman/listinfo/valentina From sunshine at public.kherson.ua Mon Mar 8 22:30:17 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 14:30:22 2004 Subject: 2.0 In-Reply-To: Message-ID: On 3/8/04 10:20 PM, "jda" wrote: Let's move this to Valentina beta list. >> I work on on NUMERIC index, >> And then I will need spend time on String index. >> On TEXT indexed by words to split it on words using new tools of ICU. >> Hopefully this is not hard. > > I hope so too, since text searching is the backbone of my app. > >> >> You say about UTF8 in db files, to save disk space? >> Is this really MPORTNAT issue? > > Yes and no. My users are individuals (not companies), and they have > to move databases around (home to work, to colleagues over the > Internet, from computer to computer in schools, etc.). So size does > become important when you're talking about 50 or more MB per database. I see. Does they compress dbs when move them? If yes, I think UTF16 must have very good compression. > It also affects speed. If I have to convert from UTF-8 (what RB uses) > to UTF-16 every time I want to add a record, it really slows things > down Jon, in fact we will do this. V4RB get string from RB in UTF8, And it MUST convert it to UTF16 internally. And may be on write down to disk convert into UTF8. This is why it can be better keep db file always in UTF16 also. >(for example, one record of mine has 34 fields, and users who > import from the Internet may added 100's of records at once. This is > a lot of conversion. Simply storing and retrieving the data as UTF-8 > means no overhead at that end. If you can index the data as UTF-8, it > also means no overhead during a search. But you know more about the > particulars of that. Well, IBM guys say that UTF8 -> UTF16 conversion is quite fast. > I think this is something that all RB users will want. MD users too, > I imagine. I think only Revolution maintains UTF-16 data, but they're > a small minority of developers I think (based upon what I see on the > list). Java also in UTF16 I think, As well a MacOS X and Windows self. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Mon Mar 8 22:31:31 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 14:31:36 2004 Subject: union In-Reply-To: Message-ID: On 3/8/04 10:20 PM, "jda" wrote: >>> 2. Concatenating cursors (you've explained to me already how to in >>> 2.0) so that I can get the union and the intersection of multiple >>> cursors. This will be very cool. >> >> We have UINON and INTERSECT on SQL level. > > Good. > >> >> I think we have not yet tests query on Cursor table. >> Must not be big problems. Important just to assign name for that tmp table >> to use it for future queries. >> >> Although I still not very sure this is good way. >> TMP table do not have indexes. It needs time to build them. > > I wouldn't need indexes, just the ability to get unions/interestions > and create a list that shows the fields I want. Problem that union REQUIRE index and sort of tables-operands. Ok, let's discuss this again little later. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Mon Mar 8 22:34:42 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 14:34:48 2004 Subject: In-Reply-To: Message-ID: On 3/8/04 10:20 PM, "jda" wrote: >> May be if you will include engine 1.x into your new app. >> You will get such transparent way. >> > > You can have both? Hm, that's a possibility. Ah sorry. I can do this in C++. Not in REALbasic. bad > If it would let you open the old db, iterate through the fields and save them > as a new db, that would do the trick. And I imagine it wouldn't add a lot to > the size of the app. Yes, this could add just 1.4 MB of 1.x engine -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From fci at europa.com Mon Mar 8 13:36:21 2004 From: fci at europa.com (Lynn Fredricks) Date: Mon Mar 8 15:36:45 2004 Subject: 2.0 In-Reply-To: Message-ID: <000201c40555$6d3538a0$0100000a@LYNNP42G> > > I think this is something that all RB users will want. MD > users too, I > > imagine. I think only Revolution maintains UTF-16 data, but > they're a > > small minority of developers I think (based upon what I see on the > > list). > > Java also in UTF16 I think, > As well a MacOS X and Windows self. UTF-8 is nice, but it isnt the format of choice for 2-byte languages like Japanese. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From sunshine at public.kherson.ua Tue Mar 9 00:10:35 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 16:10:43 2004 Subject: 2.0 In-Reply-To: <000201c40555$6d3538a0$0100000a@LYNNP42G> Message-ID: On 3/8/04 11:36 PM, "Lynn Fredricks" wrote: >>> I think this is something that all RB users will want. MD >> users too, I >>> imagine. I think only Revolution maintains UTF-16 data, but >> they're a >>> small minority of developers I think (based upon what I see on the >>> list). >> >> Java also in UTF16 I think, >> As well a MacOS X and Windows self. > > UTF-8 is nice, but it isnt the format of choice for 2-byte languages like > Japanese. Lynn, do not worry about Japan Valentina 2.0 support UTF16 as native. UTF8 will be not native for it. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 9 00:19:05 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 16:19:11 2004 Subject: 2.0 In-Reply-To: Message-ID: On 3/8/04 10:43 PM, "jda" wrote: >> Well, IBM guys say that UTF8 -> UTF16 conversion is quite fast. > > I don't know about that. It's not exactly slow in RB, but when you > have to iterate every bit of data through a textconverter (perhaps > thousands of times) it adds up. In any case we must do this. And this will do Valentina self using IBM ICU lib -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 9 00:20:43 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 8 16:20:49 2004 Subject: In-Reply-To: Message-ID: On 3/8/04 10:57 PM, "jda" wrote: >>> If it would let you open the old db, iterate through the fields >>> and save them >>> as a new db, that would do the trick. And I imagine it wouldn't add a lot >>> to >>> the size of the app. >> >> Yes, this could add just 1.4 MB of 1.x engine >> > > I wonder if you even need that. You wouldn't need any functionality > of the original engine (no sql, no tables, etc.). All you would need > would be the ability to read the old data and write it out in the new > format. Shouldn't that be much smaller? This will require special work. Hmm, may be...may be make other plugin with cutted API, And even other names of classes. Remove SQL, and other things. Not very easy but a way. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From fci at europa.com Mon Mar 8 14:28:37 2004 From: fci at europa.com (Lynn Fredricks) Date: Mon Mar 8 16:29:01 2004 Subject: 2.0 In-Reply-To: Message-ID: <002101c4055c$baa93d00$0100000a@LYNNP42G> Hi Ruslan, > > UTF-8 is nice, but it isnt the format of choice for 2-byte > languages > > like Japanese. > > Lynn, do not worry about Japan > > Valentina 2.0 support UTF16 as native. > > UTF8 will be not native for it. I know -- Im just saying that because a lot of people don't know that its hugely desirable in dealing with 2-byte markets. Its going to be a major advantage in creating truly global database applications. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From rbarber at yhb.att.ne.jp Tue Mar 9 10:17:01 2004 From: rbarber at yhb.att.ne.jp (ron barber) Date: Mon Mar 8 19:16:52 2004 Subject: 2.0 In-Reply-To: <002101c4055c$baa93d00$0100000a@LYNNP42G> References: <002101c4055c$baa93d00$0100000a@LYNNP42G> Message-ID: <77BAFE33-7167-11D8-8AED-000A95DAEEF0@yhb.att.ne.jp> Thanks Lynn and Ruslan for doing this. You are absolutely right about the 2byte market and you will be well positioned for entering it. Ron PS I worry about Japan all the time, I guess I should take Ruslan's advice! On Mar 9, 2004, at 7:28 AM, Lynn Fredricks wrote: > Hi Ruslan, > >>> UTF-8 is nice, but it isnt the format of choice for 2-byte >> languages >>> like Japanese. >> >> Lynn, do not worry about Japan >> >> Valentina 2.0 support UTF16 as native. >> >> UTF8 will be not native for it. > > I know -- Im just saying that because a lot of people don't know that > its > hugely desirable in dealing with 2-byte markets. Its going to be a > major > advantage in creating truly global database applications. From fci at europa.com Mon Mar 8 17:52:57 2004 From: fci at europa.com (Lynn Fredricks) Date: Mon Mar 8 19:53:18 2004 Subject: 2.0 In-Reply-To: <77BAFE33-7167-11D8-8AED-000A95DAEEF0@yhb.att.ne.jp> Message-ID: <006c01c40579$44434ee0$0100000a@LYNNP42G> > Thanks Lynn and Ruslan for doing this. You are absolutely right about > the 2byte market and you will be well positioned for entering it. > > Ron > > PS I worry about Japan all the time, I guess I should take Ruslan's > advice! Great! I hope you will also beat the hell out of the beta to make sure its all working right. UTF-16 support is really going to be good for us in Japan. And its always on my mind, Ron. I lived in Japan for six years and have a Japanese spouse. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From jda at his.com Mon Mar 8 21:03:28 2004 From: jda at his.com (jda) Date: Mon Mar 8 20:04:35 2004 Subject: 2.0 In-Reply-To: <20040309015321.7CEC0C8C09@edison.macserve.net> References: <20040309015321.7CEC0C8C09@edison.macserve.net> Message-ID: > >Great! I hope you will also beat the hell out of the beta to make sure its >all working right. UTF-16 support is really going to be good for us in >Japan. And its always on my mind, Ron. I lived in Japan for six years and >have a Japanese spouse. Yes, but will she buy 20,000 copies of my application? It is a huge mistake to think that Unicode support is for classic "two-byte" applications like Japanese. The majority of my Unicode users are using Hebrew, Arabic, and plain old accented "European" characters! That includes American/European users. Japan is at most 10% of the market that needs Unicode. We need unicode for "the rest of us!!!!!!!! Jon From fci at europa.com Mon Mar 8 18:29:02 2004 From: fci at europa.com (Lynn Fredricks) Date: Mon Mar 8 20:29:21 2004 Subject: 2.0 In-Reply-To: Message-ID: <007401c4057e$4eed4fd0$0100000a@LYNNP42G> > It is a huge mistake to think that Unicode support is for classic > "two-byte" applications like Japanese. I didn't say that. UTF-8 is also Unicode. It just isnt going to cut the mustard everywhere that Valentina is going to go. > The majority of my Unicode users are using Hebrew, Arabic, and plain > old accented "European" characters! That includes American/European > users. Japan is at most 10% of the market that needs Unicode. We need > unicode for "the rest of us!!!!!!!! Hogwash. The second largest, single language software market in the world is Japan. You may not be addressing the needs of that market in your own products, but that doesn't reflect the software market in general. UTF-16 doesn't take care of "the rest of us", it takes care of all of us. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From rbarber at yhb.att.ne.jp Tue Mar 9 11:38:12 2004 From: rbarber at yhb.att.ne.jp (ron barber) Date: Mon Mar 8 20:38:01 2004 Subject: 2.0 In-Reply-To: <006c01c40579$44434ee0$0100000a@LYNNP42G> References: <006c01c40579$44434ee0$0100000a@LYNNP42G> Message-ID: Lynn > Great! I hope you will also beat the hell out of the beta to make sure > its > all working right. UTF-16 support is really going to be good for us in > Japan. And its always on my mind, Ron. I lived in Japan for six years > and > have a Japanese spouse. I have an application that reads CJK files as well as Greek and English, so I'm just waiting to plug in version 2 and try it. (I'm using Rev which is trying to complete the transition to UTF-16.) I sympathize with Jon and others who worry about size and speed implications of UTF-8vs16. I'm hoping that in reality it will not be that great, since both issues, especially speed, are important in my application as well. Ron From fci at europa.com Mon Mar 8 19:10:39 2004 From: fci at europa.com (Lynn Fredricks) Date: Mon Mar 8 21:10:58 2004 Subject: 2.0 In-Reply-To: Message-ID: <008701c40584$1f604000$0100000a@LYNNP42G> > I have an application that reads CJK files as well as Greek and > English, so I'm just waiting to plug in version 2 and try it. Great! > (I'm using Rev which is trying to complete the transition to UTF-16.) > > I sympathize with Jon and others who worry about size and speed > implications of UTF-8vs16. I'm hoping that in reality it will not be > that great, since both issues, especially speed, are important in my > application as well. It isnt done cooking yet, so there's room for change, but if there's concern over it it would be a good idea to start testing as soon as you can. One of the big advantages of Valentina is speed, and we don't want to compromise that too much. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From sunshine at public.kherson.ua Tue Mar 9 10:13:46 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Tue Mar 9 02:13:52 2004 Subject: 2.0 In-Reply-To: Message-ID: On 3/9/04 12:32 AM, "jda" wrote: >>>> Well, IBM guys say that UTF8 -> UTF16 conversion is quite fast. >>> >>> I don't know about that. It's not exactly slow in RB, but when you >>> have to iterate every bit of data through a textconverter (perhaps >>> thousands of times) it adds up. >> >> In any case we must do this. >> >> And this will do Valentina self using IBM ICU lib >> > > You mean I'd send Valentina UTF-8 and it would convert/store it as > UTF-16. And when I retrieved the data Valentina would convert it and > hand it back to me as UTF-8? Yes, you will send for REALbasic just strings. REALbasic keep them in UTF8 or any other encoding. V4RB pluging will convert them to UTF16. This is possible for ANY encoding. Storage on disk is other question. There is no final decision yet. May be we will allow assign on a field option how to store it on disk. We need check what is better. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 9 10:15:47 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Tue Mar 9 02:15:53 2004 Subject: In-Reply-To: Message-ID: On 3/9/04 1:54 AM, "jda" wrote: >>> I forget, but it was larger than that (the field that has the most >>> data is compressed). >>> >>> It was over a year ago I did this. I can test it again if you want. >> >> Yes. >> >> I'd expect >> >> 13 MB + 13MB + let it be 20 MB XML = 50 MB >> >> 2 seconds on all. >> > > OK. Either it's gotten better, or I have (of course, the Mac I tried > it on before was a beige G3, and now it's an 800 mHz G4 iMac, so that > helps, too)! > > I tried a db with 3000 records. The dump was very quick, as you said > (2 seconds or less). The XML file was 5.7 MB. Reading was a lot > slower: 2.5 minutes. > > This isn't terrible, especially if there was some kind of visual > feedback (I know Valentina 2.0 will let you do that so the user sees > what is going on). > > I'm not sure conversion in memory would be all that much faster. So > maybe this will be enough. Certainly it would be fine for small > databases (<= 1 MB). I have occasional users with > 50,000 records, > so it would be a pain for them, but they only have to do it once. I > guess we'll have to see when 2.0 is available to test. > > So thanks...I'm glad I tested again. Ok, Still not fast XML parsing I think. Although we use EXPAT, they claim to be fastest. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rbarber at yhb.att.ne.jp Tue Mar 9 17:44:28 2004 From: rbarber at yhb.att.ne.jp (ron barber) Date: Tue Mar 9 02:44:15 2004 Subject: 2.0 In-Reply-To: References: Message-ID: Ruslan, On Mar 9, 2004, at 5:13 PM, Ruslan Zasukhin wrote: > Storage on disk is other question. > There is no final decision yet. > May be we will allow assign on a field option how to store it on disk. > We need check what is better. I realize that everyone's requirements are different. I would vote for speed over small storage in my particular case. The fewer conversions the better. Currently my files are stored as SJIS and converted by Revolution to UTF16 after Val retrieves them. My hope is that I can store the files in UTF16 in Val originally and skip the Rev conversion as well as any Val conversions. At one point it seems that we discussed having an option to store as UTF8 or UTF16? We now have text flds and vchar flds so we would have 8 and 16 flds options. So Val is 16 capable but we can store our data as either 8 or 16. But maybe my memory is not correct. Ron From sunshine at public.kherson.ua Tue Mar 9 11:09:42 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Tue Mar 9 03:09:51 2004 Subject: 2.0 In-Reply-To: Message-ID: On 3/9/04 10:44 AM, "ron barber" wrote: > Ruslan, > > On Mar 9, 2004, at 5:13 PM, Ruslan Zasukhin wrote: > >> Storage on disk is other question. >> There is no final decision yet. >> May be we will allow assign on a field option how to store it on disk. >> We need check what is better. > > I realize that everyone's requirements are different. I would vote for > speed over small storage in my particular case. The fewer conversions > the better. Currently my files are stored as SJIS and converted by > Revolution to UTF16 after Val retrieves them. My hope is that I can > store the files in UTF16 in Val originally and skip the Rev conversion > as well as any Val conversions. Ron, small db size also affect speed. Even better of all. Because the smaller db the faster it reads from disk, The small its size in cache, The fewer access to disk > At one point it seems that we discussed having an option to store as > UTF8 or UTF16? We now have text flds and vchar flds so we would have 8 > and 16 flds options. So Val is 16 capable but we can store our data as > either 8 or 16. But maybe my memory is not correct. Yes, we discuss exactly this. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Thu Mar 11 00:35:36 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 10 16:35:44 2004 Subject: [ALL] List of new features in Valentina 2.0 Message-ID: Hi All, I think we will start to grow list of new features that we have implement on 2.0 engine. Igor, Alex, Sergey, Ivan, Yuri, please participate in this. I will start below template of list, and let's grow it. Everybody know his tasks so mention them. So, this is FIRST DRAFT made in 10 minutes by me. ----------------------------------------------------- KERNEL ----------------------------------------------------- * UNICODE support, based on IBM ICU library. * REGEX now unicode-savy. Based on IMB ICU library. * new cache which is 100-500 times faster of Valentina 1.x cache, Especially for a big size 50-500 MB. * new internal file system, which is in 100-500 times faster of Valentina 1.x version. Difference is notable on big db files > 200MB. * RAM-based database * RAM-based table inside of disk based database. Excellent for small tmp tables. * Each Table now have virtual fields "RecID" and "OID" * Database always now have ".tmp" volume. This volume contains all temporary files (such as joins) and in case of system failure, we can start much faster, because to remove tmp files we need just delete one disk file. * DIAGNOSE of indexes. * Numeric Indexes should be faster. * non-indexed search now possible. * BINARY LINK -- new Valentina specific kind of link between 2 tables, which all link records of 2 tables as M : M without creation of third table, as require Relational model. Besides such link eat less disk space and works few times faster on JOIN. * XML dump now produce line end correct for each platform. * XML dump now can be in UTF16 format, and can be parsed. * XML dump of database now can export only Structure, Data or both. * XML dump of table. * XML import of data into a Table even if have records. * own plugin system * Error codes of Valentina now follow to SQL92 standard. * Error codes and descriptions of codes present in the public XML file. * Valentina on start parse XML file and build map of errors. * Therefore it is possible to localize XML file for different languages. * DateTime functions are extended. * Functions to get from a related table using links. For example, get_linked_count() Such functions allow avoid using of JOIN and even GROUP BY to get such kind of information. Therefore we can do such kind of queries faster and use less space on disk and RAM. ----------------------------------------------------- KERNEL (SQL) ----------------------------------------------------- * strict SQL 92 compatibility (excluding procedure part of SQL92). * SQL parser implemented with the help of industry strength parser generator ANTLR. * CREATE TABLE, now allow define: PRIMARY KEY, FOREIGN KEY, CHECK, DEFAULT VALUE * ALTER TABLE now have very reach syntax, even more reach than SQL92 offer. * in SELECT works field aliases. * you can use complex expressions directly in SELECT and WHERE statements. * SQL92 Standard way to define JOINS in the FROM statement. * sub-queries works * UNION [ALL], INTERSECT [ALL], EXCEPT [ALL] implemented. * ANY / EACH works. * EXISTS predicate. * Valentina Extensions: * CREATE LINK * DROP LINK * INSERT INTO LINK ----------------------------------------------------- C++ SDK ----------------------------------------------------- * Totally new design of classes, based on Interfaces, smart pointers. * the folder "FBL/publ" -- simple set of high level API, similar to such Valentina products as V4RB, V4MD. * The folder "FBL/prot" headers only. This level open to C++ developers access to practically the whole engine. You are be able on this level access advanced features directly, improve/tune/customize them via own implementation of interfaces. * The folder "FBL/prot" including .cpp files. In total publ + prot folders this is about 800 files. You can get access to all this for special price. ----------------------------------------------------- V4RB ----------------------------------------------------- * ability create RAM based database and tables. * V4RB plugin automatically do conversion of REALbasic strings into internal format. ----------------------------------------------------- V4MD ----------------------------------------------------- * ability create RAM based database and tables. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Thu Mar 11 00:46:07 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 10 16:46:15 2004 Subject: [ALL] List of new features in Valentina 2.0 // MORE // record lock In-Reply-To: Message-ID: On 3/11/04 12:35 AM, "Ruslan Zasukhin" wrote: KERNEL * added new record lock type: "Intention of write" -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From jda at his.com Wed Mar 10 18:18:55 2004 From: jda at his.com (jda) Date: Wed Mar 10 17:21:14 2004 Subject: 2.0 In-Reply-To: <20040310224620.49A81CAE77@edison.macserve.net> References: <20040310224620.49A81CAE77@edison.macserve.net> Message-ID: > >> The majority of my Unicode users are using Hebrew, Arabic, and plain >> old accented "European" characters! That includes American/European >> users. Japan is at most 10% of the market that needs Unicode. We need >> unicode for "the rest of us!!!!!!!! > >Hogwash. The second largest, single language software market in the world is >Japan. You may not be addressing the needs of that market in your own >products, but that doesn't reflect the software market in general. UTF-16 >doesn't take care of "the rest of us", it takes care of all of us. > I'm getting this as a digest (hm, I thought I asked for single email mode. Oh well) so I'm late to respond. Hogwash yourself, Lynn :P. Who cares if it's the second largest single language market. It pales next to US + Europe. And UTF-8 takes care of all of us, too. I have no idea what you even mean by that statement -- at face value it is simply wrong. Jon From sunshine at public.kherson.ua Thu Mar 11 01:27:14 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 10 17:27:21 2004 Subject: 2.0 In-Reply-To: Message-ID: On 3/11/04 1:18 AM, "jda" wrote: >>> The majority of my Unicode users are using Hebrew, Arabic, and plain >>> old accented "European" characters! That includes American/European >>> users. Japan is at most 10% of the market that needs Unicode. We need >>> unicode for "the rest of us!!!!!!!! >> >> Hogwash. The second largest, single language software market in the world is >> Japan. You may not be addressing the needs of that market in your own >> products, but that doesn't reflect the software market in general. UTF-16 >> doesn't take care of "the rest of us", it takes care of all of us. >> > > I'm getting this as a digest (hm, I thought I asked for single email > mode. Oh well) so I'm late to respond. You can change option > Hogwash yourself, Lynn :P. Who cares if it's the second largest > single language market. It pales next to US + Europe. And UTF-8 takes > care of all of us, too. I have no idea what you even mean by that > statement -- at face value it is simply wrong. Japan software market is bigger then the whole Europe market. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From fci at europa.com Wed Mar 10 17:18:15 2004 From: fci at europa.com (Lynn Fredricks) Date: Wed Mar 10 19:18:38 2004 Subject: 2.0 In-Reply-To: Message-ID: <000001c40706$c02f73b0$0100000a@LYNNP42G> > >Hogwash. The second largest, single language software market in the > >world is Japan. You may not be addressing the needs of that > market in > >your own products, but that doesn't reflect the software market in > >general. UTF-16 doesn't take care of "the rest of us", it > takes care of > >all of us. > > > > I'm getting this as a digest (hm, I thought I asked for single email > mode. Oh well) so I'm late to respond. > > Hogwash yourself, Lynn :P. Who cares if it's the second largest > single language market. It pales next to US + Europe. And UTF-8 takes > care of all of us, too. I have no idea what you even mean by that > statement -- at face value it is simply wrong. Okay then, balderdash! :-) We care. Your "too" excludes a good choice for Asia. Yes, you can store 2-byte info in UTF-8, its just not the choice that is optimal for the market. UTF-8 is going to be an option with Valentina 2. UTF-16 provides more choice for more markets. In many respects, Japan is as vibrant a software market as all of Europe combined, except that it's a single language market. It's a market we are targeting with Valentina 2. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From jda at his.com Wed Mar 10 20:44:58 2004 From: jda at his.com (jda) Date: Wed Mar 10 19:47:50 2004 Subject: 2.0 In-Reply-To: <000001c40706$c02f73b0$0100000a@LYNNP42G> References: <000001c40706$c02f73b0$0100000a@LYNNP42G> Message-ID: > > >Okay then, balderdash! :-) We care. Your "too" excludes a good choice for >Asia. Yes, you can store 2-byte info in UTF-8, its just not the choice that >is optimal for the market. UTF-8 is going to be an option with Valentina 2. >UTF-16 provides more choice for more markets. > >In many respects, Japan is as vibrant a software market as all of Europe >combined, except that it's a single language market. It's a market we are >targeting with Valentina 2. > I really don't disagree. But here's a reply I sent to Ruslan that didn't make the list: BTW, not to beat this to death, but ...Using the glory that is the Internet, I found this recent report on MacNN: http://www.macnn.com/news/23362 To quote the relevant bits about Apple's most recent SEC filing: * Net sales in the Americas totaled $924 million, a 25% increase over the year ago quarter * Net sales in Europe were $240 million, a 48% boost. * Sales in Japan totaled $157 million, a 14% increase. So, Europe seems to have a healthy lead over Japan as far as Apple sales goes. And with that, I will (hopefully) end this somewhat OT thread. And on topic: even the partial list of new features and abilities looks great. Jon From fci at europa.com Wed Mar 10 18:46:52 2004 From: fci at europa.com (Lynn Fredricks) Date: Wed Mar 10 20:47:14 2004 Subject: 2.0 In-Reply-To: Message-ID: <000e01c40713$21ae7170$0100000a@LYNNP42G> > To quote the relevant bits about Apple's most recent SEC filing: > > * Net sales in the Americas totaled $924 million, a 25% increase over > the year ago quarter > * Net sales in Europe were $240 million, a 48% boost. > * Sales in Japan totaled $157 million, a 14% increase. > > So, Europe seems to have a healthy lead over Japan as far as > Apple sales goes. > > And with that, I will (hopefully) end this somewhat OT thread. > > And on topic: even the partial list of new features and > abilities looks great. Not to end yet -- that is very interesting, and certainly an interesting burst of activity in Europe. Apple's done a good job to discourage sales in Japan in recent years, from canceling Tokyo Mac Expo around Apple Japan to canning the president of Apple Japan. Supporting the Mac is a differentiator for Valentina, but Id never bet the farm on being a Mac only solution, especially with a forthcoming server solution. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From rbarber at yhb.att.ne.jp Thu Mar 11 12:10:38 2004 From: rbarber at yhb.att.ne.jp (ron barber) Date: Wed Mar 10 21:10:24 2004 Subject: Apple Japan (was Re: 2.0) In-Reply-To: <000e01c40713$21ae7170$0100000a@LYNNP42G> References: <000e01c40713$21ae7170$0100000a@LYNNP42G> Message-ID: On Mar 11, 2004, at 11:46 AM, Lynn Fredricks wrote: >> And on topic: even the partial list of new features and >> abilities looks great. I second that whole-heartedly. Can't wait to get started. > burst of activity in Europe. Apple's done a good job to discourage > sales in > Japan in recent years, from canceling Tokyo Mac Expo around Apple > Japan to > canning the president of Apple Japan. On the other hand, they just opened a terrific Apple store in Ginza (Ginza, why Ginza?? name recognition? its the most expensive real estate in Japan if not the world.) I can imagine the Apple Japan president opposing this idea on the basis that it would cause bad relationships with other dealers. I really don't know how it is affecting sales overall as well as in the shops at places like Akihabara, but Japanese don't like that kind of in your face opposition. Just my 2 yen. Let's get the beta rolling! Ron From fci at europa.com Wed Mar 10 21:49:06 2004 From: fci at europa.com (Lynn Fredricks) Date: Wed Mar 10 23:49:30 2004 Subject: Apple Japan (was Re: 2.0) In-Reply-To: Message-ID: <001a01c4072c$97519c40$0100000a@LYNNP42G> > On the other hand, they just opened a terrific Apple store in Ginza > (Ginza, why Ginza?? name recognition? its the most expensive real > estate in Japan if not the world.) I can imagine the Apple Japan > president opposing this idea on the basis that it would cause bad > relationships with other dealers. I really don't know how it is > affecting sales overall as well as in the shops at places like > Akihabara, but Japanese don't like that kind of in your face > opposition. Absolutely. I doubt that was the only reason why he may have been pushed out. Apple Japan has always had a certain autonomy, but those days are gone, that's for sure. The new Apple (the one powering the Apple Stores) seems to be very effective -- its going to be interesting to see how its going to change the Mac market, over the next few years. Its sad though that there is no longer an annual show in Japan. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From sunshine at public.kherson.ua Thu Mar 11 09:37:25 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 01:37:32 2004 Subject: [ALL] List of new features in Valentina 2.0 In-Reply-To: <89D0E250-732D-11D8-8C79-000A95D87648@amug.org> Message-ID: On 3/11/04 9:27 AM, "Tim Davis" wrote: > Hi Ruslan, > I can hardly wait to get my hands on this!!! I see a lot of things > I've been waiting for a long time. I presume the "Having" clause will > be in there too (as part of strict SQL92 compatibility)? Hi Tim, Yes, although I have not implement it yet. Sergey should soon prepare SQL grammar in a short form and we will show it to beta list. I think up to the end of this month we will yet finish NEW not implemented stuff, Then we need clean up all memory leaks Then we need polish small glitches And prepare docs Then we will need make RELEASE archives for each product. Also not easy task. When you have hundreds of files. It will take time to build scripts and check them. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rblists at carsten-friehe.de Thu Mar 11 10:04:02 2004 From: rblists at carsten-friehe.de (=?iso-8859-1?Q?Carsten_Friehe?=) Date: Thu Mar 11 03:06:13 2004 Subject: [ALL] List of new features in Valentina 2.0 Message-ID: <26883301$107899556140502a6936ec52.00246564@config13.schlund.de> Hi Ruslan! > I think we will start to grow list of new features that we have implement on > 2.0 engine. Wow! > * V4RB plugin automatically do conversion of REALbasic strings into internal > format. Does it mean that we need no extra coding for this? So we can save a string from RB into Valentina with encoding xxx and when we get it back from the database we will get also the encoding back? GREAT! Carsten From sunshine at public.kherson.ua Thu Mar 11 12:23:15 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 04:23:24 2004 Subject: [V4MD] recId, Insert and Cursor question In-Reply-To: <133298055.20040311111813@ks.avalbank.com> Message-ID: On 3/11/04 11:18 AM, "Ivan Smahin" wrote: > RZ> You should use 2 query for now. > > RZ> In Valentina 2.0 it will be possible to use subquery > > RZ> INSERT INTO T (f1, ptr) > RZ> VALUES ( 'aaa', > RZ> (SELECT recID FROM Department WHERE deptName = 'FOO') ) > > RZ> Although I am not sure this syntax will works. > RZ> Ivan? > Yes, it seems to me this is not standard feature. MS-SQL does not > allow this trick but Oracle does. > We support standard approach like > INSERT INTO T (f1, ptr) > ( select 'aaa', recID FROM Department WHERE deptName = 'FOO') :-) little strange way actually, But at least a way. May be in future it is good idea make as Oracle also. > Test for this syntax is passed. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rjb at robelko.com Thu Mar 11 11:10:44 2004 From: rjb at robelko.com (Robert Brenstein) Date: Thu Mar 11 04:27:23 2004 Subject: 2.0 In-Reply-To: <000e01c40713$21ae7170$0100000a@LYNNP42G> References: <000e01c40713$21ae7170$0100000a@LYNNP42G> Message-ID: > > To quote the relevant bits about Apple's most recent SEC filing: >> >> * Net sales in the Americas totaled $924 million, a 25% increase over >> the year ago quarter >> * Net sales in Europe were $240 million, a 48% boost. >> * Sales in Japan totaled $157 million, a 14% increase. >> >> So, Europe seems to have a healthy lead over Japan as far as >> Apple sales goes. >> >> And with that, I will (hopefully) end this somewhat OT thread. >> >> And on topic: even the partial list of new features and >> abilities looks great. > >Not to end yet -- that is very interesting, and certainly an interesting >burst of activity in Europe. Apple's done a good job to discourage sales in >Japan in recent years, from canceling Tokyo Mac Expo around Apple Japan to >canning the president of Apple Japan. > >Supporting the Mac is a differentiator for Valentina, but Id never bet the >farm on being a Mac only solution, especially with a forthcoming server >solution. > >Best regards, > > >Lynn Fredricks >President >Proactive International, LLC > >http://www.proactive-intl.com One aspect that needs to be mentioned, and which skews all the arguments, is that while Japan is a 2nd largest single-language market, this language requires quite a bit of effort to support natively, so not that many programs from small developers (like many of Valentina developers are) are localized for Japanese. And that is aside from Mac-Windows issues. And if we talk markets, Chinese seems to be the rising star with potential to surpass Japan in future. But the bottom line is that the markets for products from valentina developers are likely to be somewhat different than markets for valentina self. Robert From sunshine at public.kherson.ua Thu Mar 11 13:20:00 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 05:20:08 2004 Subject: V4RB In-Reply-To: <26883301$107899556140502a6936ec52.00246564@config13.schlund.de> Message-ID: On 3/11/04 11:04 AM, "Carsten Friehe" wrote: >> * V4RB plugin automatically do conversion of REALbasic strings into internal >> format. > > Does it mean that we need no extra coding for this? So we can save a > string from RB into Valentina with encoding xxx and when we get it back > from the database we will get also the encoding back? > GREAT! Yes, question is what encoding to set when Valentina returns strings to RB. Or we need have special flag Default Or always UTF8 -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rblists at carsten-friehe.de Thu Mar 11 12:58:02 2004 From: rblists at carsten-friehe.de (=?iso-8859-1?Q?Carsten_Friehe?=) Date: Thu Mar 11 06:00:11 2004 Subject: V4RB Message-ID: <26883301$10790060294050534d924b47.72846818@config11.schlund.de> Hi Ruslan! > Yes, question is what encoding to set when Valentina returns strings to RB. The correct one. :-) > Or we need have special flag Default > Or always UTF8 I would say UTF-8 is great, but someone in Japan or so would eventually say UTF-16. But if we can set it in every select or as default at ValentinaOpen it would also be ok. What do the others think about it? Carsten From jda at his.com Thu Mar 11 08:14:39 2004 From: jda at his.com (jda) Date: Thu Mar 11 07:14:59 2004 Subject: V4RB In-Reply-To: <26883301$10790060294050534d924b47.72846818@config11.schlund.de> References: <26883301$10790060294050534d924b47.72846818@config11.schlund.de> Message-ID: > > >> Or we need have special flag Default >> Or always UTF8 > >I would say UTF-8 is great, but someone in Japan or so would eventually >say UTF-16. But if we can set it in every select or as default at >ValentinaOpen it would also be ok. >What do the others think about it? > Since RB's "native" encoding now is UTF-8, I think it makes sense to return it as that. I don't know why anyone would want to handle UTF-16 while "in" the app since at this point it's not about storage, UTF-8 handles Japanese just fine, and they would have to specifically set the encoding of string literals and editfield text to UTF-16 whenver they used them. Even if they did (would anyone here want that?) using a TextConverter to change the text encoding would be easy. Jon From sunshine at public.kherson.ua Thu Mar 11 15:18:39 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 07:18:49 2004 Subject: V4RB In-Reply-To: Message-ID: On 3/11/04 3:14 PM, "jda" wrote: >>> Or we need have special flag Default >>> Or always UTF8 >> >> I would say UTF-8 is great, but someone in Japan or so would eventually >> say UTF-16. But if we can set it in every select or as default at >> ValentinaOpen it would also be ok. >> What do the others think about it? >> > > Since RB's "native" encoding now is UTF-8, I think it makes sense to > return it as that. I don't know why anyone would want to handle > UTF-16 while "in" the app since at this point it's not about storage, > UTF-8 handles Japanese just fine, and they would have to specifically > set the encoding of string literals and editfield text to UTF-16 > whenver they used them. Even if they did (would anyone here want > that?) using a TextConverter to change the text encoding would be > easy. I think we will start with UTF8, If this will cause some problems for somebody then we improve this by additional option. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From yeomans at desuetude.com Thu Mar 11 10:01:00 2004 From: yeomans at desuetude.com (Charles Yeomans) Date: Thu Mar 11 09:01:11 2004 Subject: 2.0 In-Reply-To: References: <20040310224620.49A81CAE77@edison.macserve.net> Message-ID: On Mar 10, 2004, at 6:18 PM, jda wrote: >> >>> The majority of my Unicode users are using Hebrew, Arabic, and plain >>> old accented "European" characters! That includes American/European >>> users. Japan is at most 10% of the market that needs Unicode. We >>> need >>> unicode for "the rest of us!!!!!!!! >> >> Hogwash. The second largest, single language software market in the >> world is >> Japan. You may not be addressing the needs of that market in your own >> products, but that doesn't reflect the software market in general. >> UTF-16 >> doesn't take care of "the rest of us", it takes care of all of us. >> > > I'm getting this as a digest (hm, I thought I asked for single email > mode. Oh well) so I'm late to respond. > > Hogwash yourself, Lynn :P. Who cares if it's the second largest single > language market. It pales next to US + Europe. And UTF-8 takes care of > all of us, too. I have no idea what you even mean by that statement -- > at face value it is simply wrong. > Apple itself uses UTF-16 in Carbon; are they wrong as well? Charles Yeomans From fci at europa.com Thu Mar 11 07:12:06 2004 From: fci at europa.com (Lynn Fredricks) Date: Thu Mar 11 09:12:27 2004 Subject: 2.0 In-Reply-To: Message-ID: <000001c4077b$3e0010a0$0100000a@LYNNP42G> > One aspect that needs to be mentioned, and which skews all the > arguments, is that while Japan is a 2nd largest single-language > market, this language requires quite a bit of effort to support > natively, so not that many programs from small developers (like many > of Valentina developers are) are localized for Japanese. And that is > aside from Mac-Windows issues. And if we talk markets, Chinese seems > to be the rising star with potential to surpass Japan in future. > > But the bottom line is that the markets for products from valentina > developers are likely to be somewhat different than markets for > valentina self. In terms of this list, you are probably right, Robert. But that's no different than saying the majority of REALbasic users on the REALbasic list run by REAL probably wont target the Japanese market. Yet historically, the Japanese market has been supremely good for REALbasic (which is fully localized into Japanese) sales. I don't see much changing in China for a few years in terms of software, except I expect China to surpass India as the provider of outsourcing to the US. Piracy is absurd in China. Its better if you can pair your product with a hardware sale of some kind -- it's a little harder to duplicate -- but in some cases, not impossible. ROM copying (got any old Nintendo games you love?) is an ancient form of art there ;-) But when the Chinese market is at a point where it can pay for software, we will be ready. Don't mistake the fact that if evidence of a market isnt dripping into your email box on a daily basis, that it doesn't exist or isnt worth pursuing. A great many western vendors don't pursue it because they don't have any clue how to do so, or are unwilling to take the risk to accommodate code changes necessary to be competitive there. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From rjb at robelko.com Thu Mar 11 16:31:35 2004 From: rjb at robelko.com (Robert Brenstein) Date: Thu Mar 11 09:48:39 2004 Subject: 2.0 In-Reply-To: <000001c4077b$3e0010a0$0100000a@LYNNP42G> References: <000001c4077b$3e0010a0$0100000a@LYNNP42G> Message-ID: > > One aspect that needs to be mentioned, and which skews all the >> arguments, is that while Japan is a 2nd largest single-language >> market, this language requires quite a bit of effort to support >> natively, so not that many programs from small developers (like many >> of Valentina developers are) are localized for Japanese. And that is >> aside from Mac-Windows issues. And if we talk markets, Chinese seems >> to be the rising star with potential to surpass Japan in future. >> >> But the bottom line is that the markets for products from valentina >> developers are likely to be somewhat different than markets for >> valentina self. > >In terms of this list, you are probably right, Robert. But that's no >different than saying the majority of REALbasic users on the REALbasic list >run by REAL probably wont target the Japanese market. Yet historically, the >Japanese market has been supremely good for REALbasic (which is fully >localized into Japanese) sales. > >I don't see much changing in China for a few years in terms of software, >except I expect China to surpass India as the provider of outsourcing to the >US. Piracy is absurd in China. Its better if you can pair your product with >a hardware sale of some kind -- it's a little harder to duplicate -- but in >some cases, not impossible. ROM copying (got any old Nintendo games you >love?) is an ancient form of art there ;-) But when the Chinese market is at >a point where it can pay for software, we will be ready. > >Don't mistake the fact that if evidence of a market isnt dripping into your >email box on a daily basis, that it doesn't exist or isnt worth pursuing. A >great many western vendors don't pursue it because they don't have any clue >how to do so, or are unwilling to take the risk to accommodate code changes >necessary to be competitive there. > >Best regards, > > >Lynn Fredricks >President >Proactive International, LLC No argument from me. You basically extended what I said (or meant) :) Getting into non-western markets ain't trivial for most developers. This should not stop Paradigma of course. Robert From jda at his.com Thu Mar 11 11:01:53 2004 From: jda at his.com (jda) Date: Thu Mar 11 10:02:25 2004 Subject: 2.0 In-Reply-To: References: <20040310224620.49A81CAE77@edison.macserve.net> Message-ID: >On Mar 10, 2004, at 6:18 PM, jda wrote: > >>> >>>> The majority of my Unicode users are using Hebrew, Arabic, and plain >>>> old accented "European" characters! That includes American/European >>>> users. Japan is at most 10% of the market that needs Unicode. We need >>>> unicode for "the rest of us!!!!!!!! >>> >>>Hogwash. The second largest, single language software market in the world is >>>Japan. You may not be addressing the needs of that market in your own >>>products, but that doesn't reflect the software market in general. UTF-16 >>>doesn't take care of "the rest of us", it takes care of all of us. >>> >> >>I'm getting this as a digest (hm, I thought I asked for single >>email mode. Oh well) so I'm late to respond. >> >>Hogwash yourself, Lynn :P. Who cares if it's the second largest >>single language market. It pales next to US + Europe. And UTF-8 >>takes care of all of us, too. I have no idea what you even mean by >>that statement -- at face value it is simply wrong. >> > >Apple itself uses UTF-16 in Carbon; are they wrong as well? > I don't get your point. Lynn implied that UTF-8 wasn't as good as UTF-16 at handling Japanese. That is wrong. Jon From fci at europa.com Thu Mar 11 08:09:03 2004 From: fci at europa.com (Lynn Fredricks) Date: Thu Mar 11 10:09:23 2004 Subject: 2.0 In-Reply-To: Message-ID: <000c01c40783$32a9de40$0100000a@LYNNP42G> > No argument from me. You basically extended what I said (or meant) :) > Getting into non-western markets ain't trivial for most developers. > This should not stop Paradigma of course. Exactly :-) And something else to realize with this is that it takes away one potential stumbling block if you are using Valentina and want to enter these markets later. It's a good idea to have an understanding of the flexibility of a third party component vendor in international uses. Several years ago, I was involved with a company that generated, on average, $25 million off of a retail software product a year. A developer integrated a control (he decided to skip the corporate approval process) that provided no source access, and the control's vendor wouldn't fix globalization bugs. The end result was, about a $1 million loss in sales -- and a loss of employment for the engineer. Best regards, Lynn Fredricks President Proactive International, LLC http://www.proactive-intl.com From yeomans at desuetude.com Thu Mar 11 11:10:27 2004 From: yeomans at desuetude.com (Charles Yeomans) Date: Thu Mar 11 10:10:35 2004 Subject: 2.0 In-Reply-To: References: <20040310224620.49A81CAE77@edison.macserve.net> Message-ID: <9C96A86E-7376-11D8-8EEF-003065BB0634@desuetude.com> On Mar 11, 2004, at 11:01 AM, jda wrote: >> On Mar 10, 2004, at 6:18 PM, jda wrote: >> >>>> >>>>> The majority of my Unicode users are using Hebrew, Arabic, and >>>>> plain >>>>> old accented "European" characters! That includes >>>>> American/European >>>>> users. Japan is at most 10% of the market that needs Unicode. We >>>>> need >>>>> unicode for "the rest of us!!!!!!!! >>>> >>>> Hogwash. The second largest, single language software market in the >>>> world is >>>> Japan. You may not be addressing the needs of that market in your >>>> own >>>> products, but that doesn't reflect the software market in general. >>>> UTF-16 >>>> doesn't take care of "the rest of us", it takes care of all of us. >>>> >>> >>> I'm getting this as a digest (hm, I thought I asked for single email >>> mode. Oh well) so I'm late to respond. >>> >>> Hogwash yourself, Lynn :P. Who cares if it's the second largest >>> single language market. It pales next to US + Europe. And UTF-8 >>> takes care of all of us, too. I have no idea what you even mean by >>> that statement -- at face value it is simply wrong. >>> >> >> Apple itself uses UTF-16 in Carbon; are they wrong as well? >> > > I don't get your point. Lynn implied that UTF-8 wasn't as good as > UTF-16 at handling Japanese. That is wrong. > I suppose I don't get the point of the entire discussion. It appears to me that UTF-16 is a better choice than UTF-8 for Valentina. Charles Yeomans From jda at his.com Thu Mar 11 11:13:11 2004 From: jda at his.com (jda) Date: Thu Mar 11 10:13:43 2004 Subject: 2.0 In-Reply-To: <9C96A86E-7376-11D8-8EEF-003065BB0634@desuetude.com> References: <20040310224620.49A81CAE77@edison.macserve.net> <9C96A86E-7376-11D8-8EEF-003065BB0634@desuetude.com> Message-ID: >>> >> >>I don't get your point. Lynn implied that UTF-8 wasn't as good as >>UTF-16 at handling Japanese. That is wrong. >> >I suppose I don't get the point of the entire discussion. It appears >to me that UTF-16 is a better choice than UTF-8 for Valentina. > Why? Jon From yeomans at desuetude.com Thu Mar 11 11:52:45 2004 From: yeomans at desuetude.com (Charles Yeomans) Date: Thu Mar 11 10:52:51 2004 Subject: 2.0 In-Reply-To: References: <20040310224620.49A81CAE77@edison.macserve.net> <9C96A86E-7376-11D8-8EEF-003065BB0634@desuetude.com> Message-ID: <8515B03D-737C-11D8-8EEF-003065BB0634@desuetude.com> On Mar 11, 2004, at 11:13 AM, jda wrote: >>>> >>> >>> I don't get your point. Lynn implied that UTF-8 wasn't as good as >>> UTF-16 at handling Japanese. That is wrong. >>> >> I suppose I don't get the point of the entire discussion. It appears >> to me that UTF-16 is a better choice than UTF-8 for Valentina. >> > > Why? First of all, the storage requirements of UTF-8 v. UTF-16 aren't important; it wouldn't surprise me if the differences were dominated by the overhead of Valentina's own filesystem format. Disk space is cheap. What does matter is speed, and it appears to me that UTF-16 is better suited for the sort of string manipulation required for indexing and other such database operations. You might take a look at . Charles Yeomans From jda at his.com Thu Mar 11 12:02:36 2004 From: jda at his.com (jda) Date: Thu Mar 11 11:03:12 2004 Subject: 2.0 In-Reply-To: <8515B03D-737C-11D8-8EEF-003065BB0634@desuetude.com> References: <20040310224620.49A81CAE77@edison.macserve.net> <9C96A86E-7376-11D8-8EEF-003065BB0634@desuetude.com> <8515B03D-737C-11D8-8EEF-003065BB0634@desuetude.com> Message-ID: >>>> >>>> >>>I suppose I don't get the point of the entire discussion. It >>>appears to me that UTF-16 is a better choice than UTF-8 for >>>Valentina. >>> >> >>Why? > >First of all, the storage requirements of UTF-8 v. UTF-16 aren't >important; it wouldn't surprise me if the differences were dominated >by the overhead of Valentina's own filesystem format. Disk space is >cheap. What does matter is speed, and it appears to me that UTF-16 >is better suited for the sort of string manipulation required for >indexing and other such database operations. You might take a look >at . > If Valentina can offer both, I suggest that the developer should decide which better suits his users' needs (one could even let the user specify what storage to use as a preference). Ruslan has already said that all internal operations will use UTF-16 (as does Mac OS X and Windows). The issue of UTF-8 is really only about storage. As I said before, if supporting UTF-8 as a storage option raises significant problems (in implementation, indexing, performance, etc.) then let it be UTF-16 everywhere. Since Ruslan hasn't yet tackled text indexing issues, I guess we won't know for a bit. Jon From sunshine at public.kherson.ua Thu Mar 11 21:21:52 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 13:22:00 2004 Subject: Grammar of SQL for Valentina 2.0 Message-ID: Hi guys, You can look on it at http://paradigmasoft.com/VSQL_Parser.html Note, Safari show it in more nice way than IE. So take a look and if any questions/comments please ask. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Thu Mar 11 23:50:32 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 15:50:44 2004 Subject: Grammar of SQL for Valentina 2.0 In-Reply-To: Message-ID: On 3/11/04 9:21 PM, "Ruslan Zasukhin" wrote: > Hi guys, > > You can look on it at > > http://paradigmasoft.com/VSQL_Parser.html > > Note, Safari show it in more nice way than IE. > > So take a look and if any questions/comments please ask. I have massage file a little, so now it have better look for reading. Check it again please. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 2 23:07:25 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Thu Mar 11 16:19:37 2004 Subject: [ATTENTION] new Valentina-beta and Valentina-Ann lists Message-ID: Hi All, Our host provider have set up 2 new lists. 1) Valentina-ann List where only Paradigma will send letters about announces of a new products and builds. So this will be low traffic list. http://lists.macserve.net/mailman/listinfo/valentina-ann 2) Valentina-beta Here must be discussed beta products of Valentina. On the main Valentina list should be discussed questions related to RELEASE products. http://lists.macserve.net/mailman/listinfo/valentina-beta ------------- * So guys, please start to subscribe to the beta list. You still have yet some time before 2.0 beta testing. * yes of course we will add info about this lists to WEB pages -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- _______________________________________________ Valentina mailing list Valentina@lists.macserve.net http://lists.macserve.net/mailman/listinfo/valentina From sunshine at public.kherson.ua Mon Mar 15 09:11:47 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 15 01:12:00 2004 Subject: VServer.OpenSession In-Reply-To: Message-ID: On 3/15/04 4:44 AM, "Charles Yeomans" wrote: > I don't see how one decides whether VServer.OpenSession succeeded. > Perhaps this is one of those situations in which V4Rb might raise an > exception. Now that Rb has try-catch blocks, this is a reasonable > approach. Yes Charles! And we laready have play with exceptions in RB SDK. Works. And in 2.0 we will change error handling to exceptions in V4RB. This raise question although, how to not break code. I think that may be it is possible to have global option in V4RB UseDepricatedErrorHandling = false on default. So if developer port existed app He can set this option TRUE, and still use err codes. New apps should be developed with exceptions. May be it is possible to use both mechanizm in the same time -------- For now OpenSession error you can check from ANY Vdatabase object. Even dummy -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From nwoe at privat.utfors.se Mon Mar 15 10:32:54 2004 From: nwoe at privat.utfors.se (=?US-ASCII?Q?niklas_wormann?=) Date: Mon Mar 15 03:33:03 2004 Subject: V4RB small bug with textimport In-Reply-To: Message-ID: Hi! running V4RB using 1.10, RB 5.5.1 windows if the path to the text file you want to import contains any non_ascii characters,(haven?t tried all possible, just a a and o) nothing will be imported, although it is a valid windows path. so impcursor.ImportText(f) will yield zero records, if f.absolutepath contains non-ascii. not a show stopper, but would be nice to have fixed. regards niklas woermann From sunshine at public.kherson.ua Mon Mar 15 11:59:58 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Mon Mar 15 04:00:04 2004 Subject: V4RB small bug with textimport In-Reply-To: Message-ID: On 3/15/04 11:32 AM, "niklas wormann" wrote: > Hi! > running V4RB using 1.10, RB 5.5.1 windows > > if the path to the text file you want to import contains > any non_ascii characters,(haven?t tried all possible, just a a and o) > nothing will be imported, although it is a > valid windows path. > > so impcursor.ImportText(f) will yield zero records, if f.absolutepath > contains non-ascii. > > not a show stopper, but would be nice to have fixed. Yes, this is not only in import. In any place where paths are used. Yes we going in 2.0 support unicode paths also -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 23 21:42:10 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Tue Mar 23 13:42:21 2004 Subject: Wow, new discovery! Message-ID: Hi guys, I have found that sorting algorithms of Valentina 1.x can be significantly improved! For example, Valentina 1.x for table in million of records, For ULONG field have eat on disk 4MB for special data. - Now it will eat ZERO on disk. Or for table in 25 million of records, this will be 100MB save of disk space for EACH FIELD, on which we do sorting. More correctly on fields uchar/ushort/short/medium/umedium/long/ulong/float I.e. On major numeric fields. Very interesting! -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Tue Mar 23 22:34:17 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Tue Mar 23 14:34:30 2004 Subject: Valentina Server 2.0 will support Rendezvous Message-ID: Hi Eric, Hi All, We have take a look on Rendezvous, and yes, we believe it will be not hard plug this technology into 2.0 release. As we see, the main advantages will get 1) Valentina Studio - it will be able find and display list of local Valentina Servers self. 2) V4MD developers will be able provide really ZERO ADMINISTRATION solutions to schools. Clients will be able self locate and connect to required Valentina Server. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rblists at carsten-friehe.de Wed Mar 24 07:02:36 2004 From: rblists at carsten-friehe.de (Carsten Friehe) Date: Wed Mar 24 00:02:48 2004 Subject: Wow, new discovery! In-Reply-To: References: Message-ID: Hi Ruslan! >For example, Valentina 1.x for table in million of records, >For ULONG field have eat on disk 4MB for special data. >- Now it will eat ZERO on disk. That sounds really great! Will you be imlementing it in 1.x and does it works for 2.x also? Carsten From sunshine at public.kherson.ua Wed Mar 24 08:13:19 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 24 00:13:28 2004 Subject: Wow, new discovery! In-Reply-To: Message-ID: On 3/24/04 8:02 AM, "Carsten Friehe" wrote: Hi Carsten, >> For example, Valentina 1.x for table in million of records, >> For ULONG field have eat on disk 4MB for special data. >> - Now it will eat ZERO on disk. > > That sounds really great! > Will you be imlementing it in 1.x and does it works for 2.x also? It will be implemented only for 2.0 -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Wed Mar 24 08:29:56 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 24 00:30:04 2004 Subject: [Valentina-studio] Re: Bug with Select count(distinct) In-Reply-To: Message-ID: On 3/24/04 8:21 AM, "Ruslan Zasukhin" wrote: >>> Well, as for me, such mistakes are DEVELOPER mistakes, >>> And they can be very easy found and fixed. >>> >>> So why we must slow down self with a lots of runtime checks ?! >>> You will NOT be able ship application which can do such mistake at runtime. >>> Right? >>> >>> So what sense to have protection which will NEVER work in your RELEASE code? >> >> Um, well, I'd prefer it if it didn't crash anyway. I keep having >> intermittent crashes in V4MD when I make a simple error like referring to a >> field that doesn't exist. Perhaps these checks could be enabled via the >> debug level in force at the time? Having director crash and lose changes >> just because of something like this is hard on the developer... > > In ideal, we could have 2 version of V4RB, V4MD, ... > > Oh, guys! This is an idea. > > In 2.0 we will keep kernel of Valentina in separate DLL, > So plugin itself will be very small. And therefore it will be easy put into > archive 2 versions of plugins! > > Really good idea!!! > > DEBUG version of plugin can have A LOTS of protection. > RELEASE will have minimal or zero Ops, this must go to Valentina beta list. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From andy at foxwerk.de Wed Mar 24 09:15:46 2004 From: andy at foxwerk.de (Andy Fuchs) Date: Wed Mar 24 02:15:55 2004 Subject: Wow, new discovery! In-Reply-To: Message-ID: Given that I never had any speed issues with sorting, I rather find it interesting to see you lurking for enhancements in every area!! Cool!! -- -- Andy Fuchs -- silent movie media -- mailto:andy@foxwerk.de -- http://www.silent-movie-media.com ------------------------------------ Verkaufe: page last updated: 2. Mar. 2004 From sunshine at public.kherson.ua Wed Mar 24 11:25:15 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 24 03:25:24 2004 Subject: Wow, new discovery! In-Reply-To: Message-ID: On 3/23/04 9:42 PM, "Ruslan Zasukhin" wrote: > Hi guys, > > I have found that sorting algorithms of Valentina 1.x can be significantly > improved! > > For example, Valentina 1.x for table in million of records, > For ULONG field have eat on disk 4MB for special data. > - Now it will eat ZERO on disk. And forget to say: - ZERO time to build this structure - ZERO time to keep it up to date. > Or for table in 25 million of records, this will be 100MB save of disk space > for EACH FIELD, on which we do sorting. > > More correctly on fields > uchar/ushort/short/medium/umedium/long/ulong/float > > I.e. On major numeric fields. > > Very interesting! > -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From sunshine at public.kherson.ua Wed Mar 24 11:28:32 2004 From: sunshine at public.kherson.ua (Ruslan Zasukhin) Date: Wed Mar 24 03:28:42 2004 Subject: Wow, new discovery! In-Reply-To: Message-ID: On 3/24/04 10:15 AM, "Andy Fuchs" wrote: > Given that I never had any speed issues with sorting, I rather find it > interesting to see you lurking for enhancements in every area!! Cool!! Actually still many ways to improvement in sorting also. I will not be able implement all for 2.0 For example, in some cases, it is possible do sorting even faster than quick sort do. The main my target now is spend time to see ALL possible cases which in future I will need and prepare kernel design for this. So later it will be easy extend by new algorithms. According that you have not see any issues. If you have million table, and you do SORT the first time (and we assume search already was made, so we have index) Then Valentina spend few seconds to build that structure. On second SORT query Valentina works faster. Now for mentioned cases, we will not loose few seconds and disk space. -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] ------------------------------------------------------------- e-mail: ruslan@paradigmasoft.com web: http://www.paradigmasoft.com To subscribe to the Valentina mail list go to: http://lists.macserve.net/mailman/listinfo/valentina ------------------------------------------------------------- From rblists at carsten-friehe.de Wed Mar 24 11:16:56 2004 From: rblists at carsten-friehe.de (Carsten Friehe) Date: Wed Mar 24 04:17:10 2004 Subject: Wow, new discovery! In-Reply-To: References: Message-ID: Hi Ruslan! >> - Now it will eat ZERO on disk. > >And forget to say: > > - ZERO time to build this structure > - ZERO time to keep it up to date. You are a magician! Good that you don't wrote this on next weeks Thursday! Carsten