You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(36) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(4) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(13) |
May
(17) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Ray F. <ra...@fr...> - 2010-11-15 06:29:37
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> Hi, <br> <br> Basic256 looks exactly like what I need to teach Nepalese children programming however I am having trouble running on various Linux machines. I installed version 0.9.2 on two machines using the Ubuntu repositories. When I attempt to type in more than about 15 to 25 characters, the program hangs and I cannot type further. In fact at that point, Basic256 freezes and the only thing I can do is a forced kill.<br> <br> Both machines are running version 10.04. One is the server install with Ubuntu LXDE (Lightweight X11 Desktop Environment) as a graphical user interface. The other machine is running Kubuntu 10.04. One is a 64 bit machine, the other is a 32 bit machine. Both are English language machines. I have been successful typing in a short command <b><tt>print "it"</tt></b> which produces the results I expect.<br> <br> I have downloaded the basic256_0.9.6.48.tgz but I don't know how to install from that.<br> <br> Any suggestions that you can make would be greatly appreciated.<br> <br> Ray<br> <div class="moz-signature">-- <br> <h4>Ray Fried</h4> <br> Web: <a href="http://www.frieds.org/">Ray & Twyla's web page</a> <br> <br> <i>"My doctors told me this morning my blood pressure is down <br> so low that I can start reading the newspaper again." <br> </i> <b>- Ronald Reagan, 1987</b> </div> </body> </html> |
From: Ray F. <ra...@fr...> - 2010-11-15 06:18:38
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Again,<br> <br> I tried to register on the new forum but when I click on the link that was e-mailed back, I get a "Server not found" message. The address was <a class="moz-txt-link-freetext" href="http://forum.basic256.orgindex.php/?mode=register&id=2&key=rC72CkrjBUs4IDeAVoQh">http://forum.basic256.orgindex.php/?mode=register&id=2&key=rC72CkrjBUs4IDeAVoQh</a><br> <br> Here is the message that was sent to me:<br> <pre wrap="">Hi Rayson, welcome to the forum! To activate your account please follow this link: <a class="moz-txt-link-freetext" href="http://forum.basic256.orgindex.php?mode=register&id=2&key=rC72CkrjBUs4IDeAVoQh">http://forum.basic256.orgindex.php?mode=register&id=2&key=rC72CkrjBUs4IDeAVoQh</a> Ray</pre> <br> <br> <br> <div class="moz-signature">-- <br> <h4>Ray Fried</h4> <br> Web: <a href="http://www.frieds.org/">Ray & Twyla's web page</a> <br> <br> <i>"My doctors told me this morning my blood pressure is down <br> so low that I can start reading the newspaper again." <br> </i> <b>- Ronald Reagan, 1987</b> </div> </body> </html> |
From: Ian L. <dr...@gm...> - 2010-07-01 00:06:34
|
Apparently our German translation is missing the window title. At least that's what I get from Google Translate. I'm reminded once again that I shouldn't have wasted my time taking Latin in high school. -Ian ---------- Forwarded message ---------- From: Jürgen Krautzig <jue...@ho...> Date: 2010/6/30 Subject: BASIC 256 To: dr...@us... In der deutschen Version von BASIC 256 muss es in der Titelleiste heißen: Unbenannt ________________________________ Künftig E-Mails über Hotmail ohne Werbung versenden! -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: james r. <ji...@re...> - 2010-06-10 13:17:16
|
Sergey, Released to SVN a new version yesterday that includes real sprites!!!! I am writing a few new sample games using them and making tweaks today. I will hopefully release a new windows installer in the next day or so. Jim 2010/6/5 Sergey Irupin <web...@bi...> > Jim and all :) > > Has seen a new web-site basic256.org - it is wonderful. At once the > question - whether is a possibility to make so that a site was on 2х > languages - in English and Russian? > > Now pair new ideas. Has peeped in KTurtle in the menu the File item > "Оpen example", at a choice opens the catalogue with examples - maybe > it is necessary to make such and at us? > > Concerning work with sprites (GetSlice, PutSlice) - at us function > of check of "impacts" sprites is stipulated? > > On Monday in college there will be an assembly in occasion of years > practice of students-translators and I there shall be. I think, work > on translation will begin with Monday. > > -- > Blessing, > Sergey Irupin, RUSSIA > |
From: Sergey I. <web...@bi...> - 2010-06-05 11:03:07
|
Jim and all :) Has seen a new web-site basic256.org - it is wonderful. At once the question - whether is a possibility to make so that a site was on 2х languages - in English and Russian? Now pair new ideas. Has peeped in KTurtle in the menu the File item "Оpen example", at a choice opens the catalogue with examples - maybe it is necessary to make such and at us? Concerning work with sprites (GetSlice, PutSlice) - at us function of check of "impacts" sprites is stipulated? On Monday in college there will be an assembly in occasion of years practice of students-translators and I there shall be. I think, work on translation will begin with Monday. -- Blessing, Sergey Irupin, RUSSIA |
From: Sergey I. <web...@bi...> - 2010-05-17 14:05:42
|
Jim, > I just committed a re-write of the documentation window to use the QWebKit. > The links now work. Please test under LINUX, my daughter took the UBUNTU > development laptop to school. Your idea was a good one but I wanted a > single help HTML file and not a directory full of them. I compiled the new version and checked - yes, now links work. I understand that you may be convenient to have only one help-file, but the navigation on this file, as this is not very convenient. Need a search on behalf of the team and index. Using multiple html files (for each team - file) - is the first step toward context help, when we put the cursor on the command, press F1 - and get help on this team. To do this, using only one help-file, I think, would be difficult. -- Blessing, Sergey Irupin, RUSSIA |
From: Sergey I. <web...@bi...> - 2010-05-14 07:03:37
|
Colleagues, I think that will be good and useful to reconstruct the history of project changes in the file ChangeLog. I see that Jim had something done and I am also a little "had a hand". That attachment file history, where I tried to show - How are new features from version to version (documentation). Something does not match - probably need to fix or documentation or the ChangeLog. And finally I want to ask again - what will be done with the website? I could have them do, what do you say? -- Blessing, Sergey Irupin, RUSSIA |
From: james r. <ji...@re...> - 2010-05-11 03:17:59
|
Hey all, Added a documentation viewer window to the help menu from the IDE. Had to make several changes to the help file and it's location to make it work well. You will see a new folder called doc/help. This will contain the files necessary for help in all of the locales. The help window will figure out what locale you are in and if it can will display the correct file (default to en). The help folder needs to be installed on LINUX boxes as /usr/share/basic256/help and should be in the binary install folder on Windows as .\help The windows installer has been updated and I am uploading it in a moment. Jim *--------- James Reneau - Assistant Professor Department of Business Administration Shawnee State University, 940 Second St, Portsmouth, OH 45662 jr...@sh... - 740-351-3556 * |
From: Sergey I. <web...@bi...> - 2010-05-10 06:58:10
|
Colleagues, Please accept my congratulations on the occasion of the victory over Nazi Germany - Yesterday we in Russia have been great celebrations. The day before yesterday we had a karate tournament dedicated to Victory Day - I was able to take a place (in its category), and my wife (in team) - 2nd. This is so, as a lyrical digression :) > With all of these updates included, I have just built and > released the 0.9.6c windows installer. I downloaded and installed - Russian interface for some reason does not include :( > Have you gotten a chance to think about the web site? I am ready to work on the site, I own HTML and PHP and have experience of such work. I have an idea how to completely transform the site, but you can maintain it and so what is there. How to solve the team? I have another idea, and 2 questions. Idea: About menu item should be added "Help" in his choice let (for example) in your browser starts documentation. For users of Windows, it can not relevant, because such an item is in the menu "Pusk/Programmy/BASIC256", but for Linux users, it would be convenient. 1 question: How can I "collect" BASIC256 in Windows? Maybe you, Jim, give me brief instructions? 2 question: File trunk/ChangeLog ceased to change with 2009-11-05. I think it is not very good, is not it? Regain its contents and will make the information there as you make new features and bug fixes. -- Blessing, Sergey Irupin, RUSSIA |
From: <web...@bi...> - 2010-05-03 06:20:11
|
Jim, Ian I'm happy with UTF8 strings we have grasped the full understanding:) And now do not need to make any patches for this. > Does anyone know how to update the web site? We have a French > translation that could go up there, but I'm not able to update it like > I used to. Yes, good question. I changed a few files in the / docs on the site but these changes I saw. I could support the Russian section of the site. And there is another important issue. I think you need to restore the file /trunc/ChangeLog. The last entry there refers to the version 0.9.3o and now we have version 0.9.6a -- Blessing, Sergei Irupin http://rnd-lug.blogspot.com/ |
From: Ian L. <dr...@gm...> - 2010-05-02 19:36:00
|
Thanks Jim! Does anyone know how to update the web site? We have a French translation that could go up there, but I'm not able to update it like I used to. -Ian On Sun, May 2, 2010 at 3:19 PM, james reneau <ji...@re...> wrote: > Agreed, I have committed my changes and created a new windows install > 0.9.6a. > > Jim > > On Sun, May 2, 2010 at 2:50 PM, Ian Larsen <dr...@gm...> wrote: >> >> Even if the Utf8 functions were slower, I think simplicity would still >> be more of a factor than speed in this case. How often is performance >> dependent on manipulating strings in a tight loop? >> >> Better a performance hit than having to explain Unicode to a new >> programmer. >> >> -Ian >> >> >> On Sun, May 2, 2010 at 1:42 PM, james reneau <ji...@re...> wrote: >> > Wow, >> > >> > You are right Ian. I just ran the following benchmark and the U >> > functions >> > were faster 9 to 16 seconds. I ran it multiple times (and reversed) and >> > got >> > the same results. I will change all of the existing string functions to >> > the >> > new UNICODE safe code, remove my test/working U functions, and will >> > commit >> > later. >> > >> > I am glad you were there to tell me to keep it simple. >> > >> > Jim >> > >> > a$ = "abcdef ghijklmno pqrstuvwxyzabcd efghijklmnopqr stuvwxyzabcd >> > efghijklmnopq rs tuvwxyza bcdefghijklm nopqrstuvwxyza bcdefghijklmno >> > pqrstuvwxyzabcde fghijklmnopqrstuvwxy zabcdefghijklmnopq >> > rstuvwxyzabcdefgh >> > ijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwx >> > yzabcdefghijklmnopqrstuvwxyza >> > bcdefghijklmnopq rstuvwxyzabcdefghi jklmnopqrstuvwxyz" >> > >> > start = hour * 60 * 60 + minute * 60 + second >> > >> > for r = 1 to 1000 >> > >> > for n = 1 to ulength(a$) >> > >> > c = useq(umid(a$,n,1)) >> > >> > c$ = uchr(c) >> > >> > b$ = uleft(a$,n) >> > >> > b$ = uright(a$,n) >> > >> > next n >> > >> > next r >> > >> > finish = hour * 60 * 60 + minute * 60 + second >> > >> > print finish - start >> > >> > start = hour * 60 * 60 + minute * 60 + second >> > >> > for r = 1 to 1000 >> > >> > for n = 1 to length(a$) >> > >> > c = asc(mid(a$,n,1)) >> > >> > c$ = chr(c) >> > >> > b$ = left(a$,n) >> > >> > b$ = right(a$,n) >> > >> > next n >> > >> > next r >> > >> > finish = hour * 60 * 60 + minute * 60 + second >> > >> > print finish - start >> > >> > >> > On Sun, May 2, 2010 at 1:26 PM, james reneau <ji...@re...> wrote: >> >> >> >> Ian, >> >> >> >> The U functions do a whole bunch of additional conversion from the >> >> char* >> >> in utf8 to qstring and then back again to char* utf8. For those of us >> >> in >> >> the ASCII/English world I thought it would be slower. Havn't done a >> >> benchmark. Let me do one before I push. >> >> >> >> Jim >> >> >> >> >> >> >> >> On Sun, May 2, 2010 at 12:51 PM, Ian Larsen <dr...@gm...> wrote: >> >>> >> >>> For the sake of simplicity, why don't you just have your U* functions >> >>> just replace the default? For ASCII strings they should do the same >> >>> thing as the regular ones. >> >>> >> >>> -Ian >> >>> >> >>> On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: >> >>> > Guys, >> >>> > >> >>> > I have gotten the save and load to work with UTF8 and I am adding >> >>> > string >> >>> > functions to handle unicode (ULENGTH, USEQ, >> >>> UCHR, UMUD, ULEFT, URIGHT, >> >>> > UINSTR) and should have them committed later today. >> >>> > >> >>> > Jim >> >>> > >> >>> > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> >> >>> > wrote: >> >>> >> >> >>> >> Here's a screenshot of the result. >> >>> >> >> >>> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> >> >>> >> wrote: >> >>> >> > It's even simpler than that. You just have to change most of the >> >>> >> > QString::toAscii calls to QString::toUtf8. >> >>> >> > >> >>> >> > My changes are committed. I've tried to test everything I could >> >>> >> > but >> >>> >> > more extensive testing would ensure I've got everything. If you >> >>> >> > see >> >>> >> > question marks instead of extended characters anywhere, please >> >>> >> > let >> >>> >> > me >> >>> >> > know. >> >>> >> > >> >>> >> > -Ian >> >>> >> > >> >>> >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> >> >>> >> > wrote: >> >>> >> >> Ian, >> >>> >> >> >> >>> >> >> That was my thought, too. I was going to email you to see if we >> >>> >> >> could >> >>> >> >> change all the char* stuff in the stack and interpreter to >> >>> >> >> QStrings? >> >>> >> >> >> >>> >> >> Looking forward to your commit. >> >>> >> >> >> >>> >> >> Jim >> >>> >> >> >> >>> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> >> >>> >> >> wrote: >> >>> >> >>> >> >>> >> >>> All, >> >>> >> >>> >> >>> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem >> >>> >> >>> was >> >>> >> >>> with the way QStrings were being converted. I have a working >> >>> >> >>> version >> >>> >> >>> that I'm going to test some more and commit tomorrow. >> >>> >> >>> >> >>> >> >>> -Ian >> >>> >> >>> >> >>> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> >> >>> >> >>> wrote: >> >>> >> >>> > All, >> >>> >> >>> > >> >>> >> >>> > I believe the reason you're seeing the question marks in the >> >>> >> >>> > output >> >>> >> >>> > is >> >>> >> >>> > because Gnu Flex and Bison, which the basic256 parser is >> >>> >> >>> > written >> >>> >> >>> > in, >> >>> >> >>> > doesn't support Unicode at all. >> >>> >> >>> > >> >>> >> >>> > There are no simple fixes for this, unfortunately. Here are >> >>> >> >>> > some >> >>> >> >>> > possibilities: >> >>> >> >>> > >> >>> >> >>> > 1) Encode ALL strings in a program's source code using base64 >> >>> >> >>> > and >> >>> >> >>> > then >> >>> >> >>> > decode them prior to pushing them onto the operand stack. >> >>> >> >>> > This >> >>> >> >>> > is >> >>> >> >>> > an >> >>> >> >>> > ugly hack, but right now would be the path of least >> >>> >> >>> > resistance. >> >>> >> >>> > 2) Find a drop-in replacement for Flex and Bison that >> >>> >> >>> > supports >> >>> >> >>> > Unicode >> >>> >> >>> > 3) Write a custom parser that supports Unicode. This would >> >>> >> >>> > be a >> >>> >> >>> > *lot* >> >>> >> >>> > of work, but would be a lot of fun for someone interested in >> >>> >> >>> > learning >> >>> >> >>> > compiler design. >> >>> >> >>> > >> >>> >> >>> > If anyone has any other ideas, please let me know. >> >>> >> >>> > >> >>> >> >>> > -Ian >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> >> >>> >> >>> > wrote: >> >>> >> >>> >> Ian, >> >>> >> >>> >> >> >>> >> >>> >> I am very glad that you have returned to the development >> >>> >> >>> >> BASIC256! >> >>> >> >>> >> I >> >>> >> >>> >> would just tell you about a serious problem that exists for >> >>> >> >>> >> users >> >>> >> >>> >> who >> >>> >> >>> >> use the Russian language. Attached - screenshot. >> >>> >> >>> >> >> >>> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 >> >>> >> >>> >> for >> >>> >> >>> >> the >> >>> >> >>> >> distribution of ALT Linux. Of course, this patch is not >> >>> >> >>> >> urgent, >> >>> >> >>> >> since >> >>> >> >>> >> you have done a lot of changes. Can I ask you to make >> >>> >> >>> >> necessary >> >>> >> >>> >> changes (because I have little experience) or the provision >> >>> >> >>> >> of >> >>> >> >>> >> Russian-speaking users - only my problem? :-) >> >>> >> >>> >> >> >>> >> >>> >>> On this list about two weeks ago we got a french >> >>> >> >>> >>> translation >> >>> >> >>> >>> if >> >>> >> >>> >>> anyone >> >>> >> >>> >>> would like to add that in. If not, I'll get around to it >> >>> >> >>> >>> eventually. >> >>> >> >>> >> >> >>> >> >>> >> I have a little more experience, so it's better if you did. >> >>> >> >>> >> >> >>> >> >>> >> -- >> >>> >> >>> >> Blessing, >> >>> >> >>> >> Sergei Irupin >> >>> >> >>> >> http://rnd-lug.blogspot.com/ >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > -- >> >>> >> >>> > My PGP Public Key: >> >>> >> >>> > http://www.scrapshark.com/pubkey.txt >> >>> >> >>> > >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> My PGP Public Key: >> >>> >> >>> http://www.scrapshark.com/pubkey.txt >> >>> >> >>> >> >>> >> >> >> >>> >> >> >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > -- >> >>> >> > My PGP Public Key: >> >>> >> > http://www.scrapshark.com/pubkey.txt >> >>> >> > >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> My PGP Public Key: >> >>> >> http://www.scrapshark.com/pubkey.txt >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> My PGP Public Key: >> >>> http://www.scrapshark.com/pubkey.txt >> >>> >> >> >> > >> > >> >> >> >> -- >> My PGP Public Key: >> http://www.scrapshark.com/pubkey.txt >> > > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: james r. <ji...@re...> - 2010-05-02 19:19:39
|
Agreed, I have committed my changes and created a new windows install 0.9.6a. Jim On Sun, May 2, 2010 at 2:50 PM, Ian Larsen <dr...@gm...> wrote: > Even if the Utf8 functions were slower, I think simplicity would still > be more of a factor than speed in this case. How often is performance > dependent on manipulating strings in a tight loop? > > Better a performance hit than having to explain Unicode to a new > programmer. > > -Ian > > > On Sun, May 2, 2010 at 1:42 PM, james reneau <ji...@re...> wrote: > > Wow, > > > > You are right Ian. I just ran the following benchmark and the U > functions > > were faster 9 to 16 seconds. I ran it multiple times (and reversed) and > got > > the same results. I will change all of the existing string functions to > the > > new UNICODE safe code, remove my test/working U functions, and will > commit > > later. > > > > I am glad you were there to tell me to keep it simple. > > > > Jim > > > > a$ = "abcdef ghijklmno pqrstuvwxyzabcd efghijklmnopqr stuvwxyzabcd > > efghijklmnopq rs tuvwxyza bcdefghijklm nopqrstuvwxyza bcdefghijklmno > > pqrstuvwxyzabcde fghijklmnopqrstuvwxy zabcdefghijklmnopq > rstuvwxyzabcdefgh > > ijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwx yzabcdefghijklmnopqrstuvwxyza > > bcdefghijklmnopq rstuvwxyzabcdefghi jklmnopqrstuvwxyz" > > > > start = hour * 60 * 60 + minute * 60 + second > > > > for r = 1 to 1000 > > > > for n = 1 to ulength(a$) > > > > c = useq(umid(a$,n,1)) > > > > c$ = uchr(c) > > > > b$ = uleft(a$,n) > > > > b$ = uright(a$,n) > > > > next n > > > > next r > > > > finish = hour * 60 * 60 + minute * 60 + second > > > > print finish - start > > > > start = hour * 60 * 60 + minute * 60 + second > > > > for r = 1 to 1000 > > > > for n = 1 to length(a$) > > > > c = asc(mid(a$,n,1)) > > > > c$ = chr(c) > > > > b$ = left(a$,n) > > > > b$ = right(a$,n) > > > > next n > > > > next r > > > > finish = hour * 60 * 60 + minute * 60 + second > > > > print finish - start > > > > > > On Sun, May 2, 2010 at 1:26 PM, james reneau <ji...@re...> wrote: > >> > >> Ian, > >> > >> The U functions do a whole bunch of additional conversion from the char* > >> in utf8 to qstring and then back again to char* utf8. For those of us > in > >> the ASCII/English world I thought it would be slower. Havn't done a > >> benchmark. Let me do one before I push. > >> > >> Jim > >> > >> > >> > >> On Sun, May 2, 2010 at 12:51 PM, Ian Larsen <dr...@gm...> wrote: > >>> > >>> For the sake of simplicity, why don't you just have your U* functions > >>> just replace the default? For ASCII strings they should do the same > >>> thing as the regular ones. > >>> > >>> -Ian > >>> > >>> On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: > >>> > Guys, > >>> > > >>> > I have gotten the save and load to work with UTF8 and I am adding > >>> > string > >>> > functions to handle unicode (ULENGTH, USEQ, > >>> UCHR, UMUD, ULEFT, URIGHT, > >>> > UINSTR) and should have them committed later today. > >>> > > >>> > Jim > >>> > > >>> > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> > wrote: > >>> >> > >>> >> Here's a screenshot of the result. > >>> >> > >>> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> > wrote: > >>> >> > It's even simpler than that. You just have to change most of the > >>> >> > QString::toAscii calls to QString::toUtf8. > >>> >> > > >>> >> > My changes are committed. I've tried to test everything I could > but > >>> >> > more extensive testing would ensure I've got everything. If you > see > >>> >> > question marks instead of extended characters anywhere, please let > >>> >> > me > >>> >> > know. > >>> >> > > >>> >> > -Ian > >>> >> > > >>> >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> > wrote: > >>> >> >> Ian, > >>> >> >> > >>> >> >> That was my thought, too. I was going to email you to see if we > >>> >> >> could > >>> >> >> change all the char* stuff in the stack and interpreter to > >>> >> >> QStrings? > >>> >> >> > >>> >> >> Looking forward to your commit. > >>> >> >> > >>> >> >> Jim > >>> >> >> > >>> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> All, > >>> >> >>> > >>> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem > >>> >> >>> was > >>> >> >>> with the way QStrings were being converted. I have a working > >>> >> >>> version > >>> >> >>> that I'm going to test some more and commit tomorrow. > >>> >> >>> > >>> >> >>> -Ian > >>> >> >>> > >>> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> > >>> >> >>> wrote: > >>> >> >>> > All, > >>> >> >>> > > >>> >> >>> > I believe the reason you're seeing the question marks in the > >>> >> >>> > output > >>> >> >>> > is > >>> >> >>> > because Gnu Flex and Bison, which the basic256 parser is > written > >>> >> >>> > in, > >>> >> >>> > doesn't support Unicode at all. > >>> >> >>> > > >>> >> >>> > There are no simple fixes for this, unfortunately. Here are > >>> >> >>> > some > >>> >> >>> > possibilities: > >>> >> >>> > > >>> >> >>> > 1) Encode ALL strings in a program's source code using base64 > >>> >> >>> > and > >>> >> >>> > then > >>> >> >>> > decode them prior to pushing them onto the operand stack. > This > >>> >> >>> > is > >>> >> >>> > an > >>> >> >>> > ugly hack, but right now would be the path of least > resistance. > >>> >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports > >>> >> >>> > Unicode > >>> >> >>> > 3) Write a custom parser that supports Unicode. This would be > a > >>> >> >>> > *lot* > >>> >> >>> > of work, but would be a lot of fun for someone interested in > >>> >> >>> > learning > >>> >> >>> > compiler design. > >>> >> >>> > > >>> >> >>> > If anyone has any other ideas, please let me know. > >>> >> >>> > > >>> >> >>> > -Ian > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> > >>> >> >>> > wrote: > >>> >> >>> >> Ian, > >>> >> >>> >> > >>> >> >>> >> I am very glad that you have returned to the development > >>> >> >>> >> BASIC256! > >>> >> >>> >> I > >>> >> >>> >> would just tell you about a serious problem that exists for > >>> >> >>> >> users > >>> >> >>> >> who > >>> >> >>> >> use the Russian language. Attached - screenshot. > >>> >> >>> >> > >>> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 > >>> >> >>> >> for > >>> >> >>> >> the > >>> >> >>> >> distribution of ALT Linux. Of course, this patch is not > urgent, > >>> >> >>> >> since > >>> >> >>> >> you have done a lot of changes. Can I ask you to make > necessary > >>> >> >>> >> changes (because I have little experience) or the provision > of > >>> >> >>> >> Russian-speaking users - only my problem? :-) > >>> >> >>> >> > >>> >> >>> >>> On this list about two weeks ago we got a french translation > >>> >> >>> >>> if > >>> >> >>> >>> anyone > >>> >> >>> >>> would like to add that in. If not, I'll get around to it > >>> >> >>> >>> eventually. > >>> >> >>> >> > >>> >> >>> >> I have a little more experience, so it's better if you did. > >>> >> >>> >> > >>> >> >>> >> -- > >>> >> >>> >> Blessing, > >>> >> >>> >> Sergei Irupin > >>> >> >>> >> http://rnd-lug.blogspot.com/ > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > -- > >>> >> >>> > My PGP Public Key: > >>> >> >>> > http://www.scrapshark.com/pubkey.txt > >>> >> >>> > > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> -- > >>> >> >>> My PGP Public Key: > >>> >> >>> http://www.scrapshark.com/pubkey.txt > >>> >> >>> > >>> >> >> > >>> >> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > -- > >>> >> > My PGP Public Key: > >>> >> > http://www.scrapshark.com/pubkey.txt > >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> My PGP Public Key: > >>> >> http://www.scrapshark.com/pubkey.txt > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> My PGP Public Key: > >>> http://www.scrapshark.com/pubkey.txt > >>> > >> > > > > > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > > |
From: Ian L. <dr...@gm...> - 2010-05-02 18:50:20
|
Even if the Utf8 functions were slower, I think simplicity would still be more of a factor than speed in this case. How often is performance dependent on manipulating strings in a tight loop? Better a performance hit than having to explain Unicode to a new programmer. -Ian On Sun, May 2, 2010 at 1:42 PM, james reneau <ji...@re...> wrote: > Wow, > > You are right Ian. I just ran the following benchmark and the U functions > were faster 9 to 16 seconds. I ran it multiple times (and reversed) and got > the same results. I will change all of the existing string functions to the > new UNICODE safe code, remove my test/working U functions, and will commit > later. > > I am glad you were there to tell me to keep it simple. > > Jim > > a$ = "abcdef ghijklmno pqrstuvwxyzabcd efghijklmnopqr stuvwxyzabcd > efghijklmnopq rs tuvwxyza bcdefghijklm nopqrstuvwxyza bcdefghijklmno > pqrstuvwxyzabcde fghijklmnopqrstuvwxy zabcdefghijklmnopq rstuvwxyzabcdefgh > ijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwx yzabcdefghijklmnopqrstuvwxyza > bcdefghijklmnopq rstuvwxyzabcdefghi jklmnopqrstuvwxyz" > > start = hour * 60 * 60 + minute * 60 + second > > for r = 1 to 1000 > > for n = 1 to ulength(a$) > > c = useq(umid(a$,n,1)) > > c$ = uchr(c) > > b$ = uleft(a$,n) > > b$ = uright(a$,n) > > next n > > next r > > finish = hour * 60 * 60 + minute * 60 + second > > print finish - start > > start = hour * 60 * 60 + minute * 60 + second > > for r = 1 to 1000 > > for n = 1 to length(a$) > > c = asc(mid(a$,n,1)) > > c$ = chr(c) > > b$ = left(a$,n) > > b$ = right(a$,n) > > next n > > next r > > finish = hour * 60 * 60 + minute * 60 + second > > print finish - start > > > On Sun, May 2, 2010 at 1:26 PM, james reneau <ji...@re...> wrote: >> >> Ian, >> >> The U functions do a whole bunch of additional conversion from the char* >> in utf8 to qstring and then back again to char* utf8. For those of us in >> the ASCII/English world I thought it would be slower. Havn't done a >> benchmark. Let me do one before I push. >> >> Jim >> >> >> >> On Sun, May 2, 2010 at 12:51 PM, Ian Larsen <dr...@gm...> wrote: >>> >>> For the sake of simplicity, why don't you just have your U* functions >>> just replace the default? For ASCII strings they should do the same >>> thing as the regular ones. >>> >>> -Ian >>> >>> On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: >>> > Guys, >>> > >>> > I have gotten the save and load to work with UTF8 and I am adding >>> > string >>> > functions to handle unicode (ULENGTH, USEQ, >>> UCHR, UMUD, ULEFT, URIGHT, >>> > UINSTR) and should have them committed later today. >>> > >>> > Jim >>> > >>> > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> wrote: >>> >> >>> >> Here's a screenshot of the result. >>> >> >>> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: >>> >> > It's even simpler than that. You just have to change most of the >>> >> > QString::toAscii calls to QString::toUtf8. >>> >> > >>> >> > My changes are committed. I've tried to test everything I could but >>> >> > more extensive testing would ensure I've got everything. If you see >>> >> > question marks instead of extended characters anywhere, please let >>> >> > me >>> >> > know. >>> >> > >>> >> > -Ian >>> >> > >>> >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: >>> >> >> Ian, >>> >> >> >>> >> >> That was my thought, too. I was going to email you to see if we >>> >> >> could >>> >> >> change all the char* stuff in the stack and interpreter to >>> >> >> QStrings? >>> >> >> >>> >> >> Looking forward to your commit. >>> >> >> >>> >> >> Jim >>> >> >> >>> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> >>> >> >> wrote: >>> >> >>> >>> >> >>> All, >>> >> >>> >>> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem >>> >> >>> was >>> >> >>> with the way QStrings were being converted. I have a working >>> >> >>> version >>> >> >>> that I'm going to test some more and commit tomorrow. >>> >> >>> >>> >> >>> -Ian >>> >> >>> >>> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> >>> >> >>> wrote: >>> >> >>> > All, >>> >> >>> > >>> >> >>> > I believe the reason you're seeing the question marks in the >>> >> >>> > output >>> >> >>> > is >>> >> >>> > because Gnu Flex and Bison, which the basic256 parser is written >>> >> >>> > in, >>> >> >>> > doesn't support Unicode at all. >>> >> >>> > >>> >> >>> > There are no simple fixes for this, unfortunately. Here are >>> >> >>> > some >>> >> >>> > possibilities: >>> >> >>> > >>> >> >>> > 1) Encode ALL strings in a program's source code using base64 >>> >> >>> > and >>> >> >>> > then >>> >> >>> > decode them prior to pushing them onto the operand stack. This >>> >> >>> > is >>> >> >>> > an >>> >> >>> > ugly hack, but right now would be the path of least resistance. >>> >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports >>> >> >>> > Unicode >>> >> >>> > 3) Write a custom parser that supports Unicode. This would be a >>> >> >>> > *lot* >>> >> >>> > of work, but would be a lot of fun for someone interested in >>> >> >>> > learning >>> >> >>> > compiler design. >>> >> >>> > >>> >> >>> > If anyone has any other ideas, please let me know. >>> >> >>> > >>> >> >>> > -Ian >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> >>> >> >>> > wrote: >>> >> >>> >> Ian, >>> >> >>> >> >>> >> >>> >> I am very glad that you have returned to the development >>> >> >>> >> BASIC256! >>> >> >>> >> I >>> >> >>> >> would just tell you about a serious problem that exists for >>> >> >>> >> users >>> >> >>> >> who >>> >> >>> >> use the Russian language. Attached - screenshot. >>> >> >>> >> >>> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 >>> >> >>> >> for >>> >> >>> >> the >>> >> >>> >> distribution of ALT Linux. Of course, this patch is not urgent, >>> >> >>> >> since >>> >> >>> >> you have done a lot of changes. Can I ask you to make necessary >>> >> >>> >> changes (because I have little experience) or the provision of >>> >> >>> >> Russian-speaking users - only my problem? :-) >>> >> >>> >> >>> >> >>> >>> On this list about two weeks ago we got a french translation >>> >> >>> >>> if >>> >> >>> >>> anyone >>> >> >>> >>> would like to add that in. If not, I'll get around to it >>> >> >>> >>> eventually. >>> >> >>> >> >>> >> >>> >> I have a little more experience, so it's better if you did. >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Blessing, >>> >> >>> >> Sergei Irupin >>> >> >>> >> http://rnd-lug.blogspot.com/ >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > -- >>> >> >>> > My PGP Public Key: >>> >> >>> > http://www.scrapshark.com/pubkey.txt >>> >> >>> > >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> My PGP Public Key: >>> >> >>> http://www.scrapshark.com/pubkey.txt >>> >> >>> >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > My PGP Public Key: >>> >> > http://www.scrapshark.com/pubkey.txt >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> My PGP Public Key: >>> >> http://www.scrapshark.com/pubkey.txt >>> > >>> > >>> >>> >>> >>> -- >>> My PGP Public Key: >>> http://www.scrapshark.com/pubkey.txt >>> >> > > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: james r. <ji...@re...> - 2010-05-02 17:42:46
|
Wow, You are right Ian. I just ran the following benchmark and the U functions were faster 9 to 16 seconds. I ran it multiple times (and reversed) and got the same results. I will change all of the existing string functions to the new UNICODE safe code, remove my test/working U functions, and will commit later. I am glad you were there to tell me to keep it simple. Jim a$ = "abcdef ghijklmno pqrstuvwxyzabcd efghijklmnopqr stuvwxyzabcd efghijklmnopq rs tuvwxyza bcdefghijklm nopqrstuvwxyza bcdefghijklmno pqrstuvwxyzabcde fghijklmnopqrstuvwxy zabcdefghijklmnopq rstuvwxyzabcdefgh ijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwx yzabcdefghijklmnopqrstuvwxyza bcdefghijklmnopq rstuvwxyzabcdefghi jklmnopqrstuvwxyz" start = hour * 60 * 60 + minute * 60 + second for r = 1 to 1000 for n = 1 to ulength(a$) c = useq(umid(a$,n,1)) c$ = uchr(c) b$ = uleft(a$,n) b$ = uright(a$,n) next n next r finish = hour * 60 * 60 + minute * 60 + second print finish - start start = hour * 60 * 60 + minute * 60 + second for r = 1 to 1000 for n = 1 to length(a$) c = asc(mid(a$,n,1)) c$ = chr(c) b$ = left(a$,n) b$ = right(a$,n) next n next r finish = hour * 60 * 60 + minute * 60 + second print finish - start On Sun, May 2, 2010 at 1:26 PM, james reneau <ji...@re...> wrote: > Ian, > > The U functions do a whole bunch of additional conversion from the char* in > utf8 to qstring and then back again to char* utf8. For those of us in the > ASCII/English world I thought it would be slower. Havn't done a benchmark. > Let me do one before I push. > > Jim > > > > > On Sun, May 2, 2010 at 12:51 PM, Ian Larsen <dr...@gm...> wrote: > >> For the sake of simplicity, why don't you just have your U* functions >> just replace the default? For ASCII strings they should do the same >> thing as the regular ones. >> >> -Ian >> >> On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: >> > Guys, >> > >> > I have gotten the save and load to work with UTF8 and I am adding string >> > functions to handle unicode (ULENGTH, USEQ, >> UCHR, UMUD, ULEFT, URIGHT, >> > UINSTR) and should have them committed later today. >> > >> > Jim >> > >> > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> wrote: >> >> >> >> Here's a screenshot of the result. >> >> >> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: >> >> > It's even simpler than that. You just have to change most of the >> >> > QString::toAscii calls to QString::toUtf8. >> >> > >> >> > My changes are committed. I've tried to test everything I could but >> >> > more extensive testing would ensure I've got everything. If you see >> >> > question marks instead of extended characters anywhere, please let me >> >> > know. >> >> > >> >> > -Ian >> >> > >> >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: >> >> >> Ian, >> >> >> >> >> >> That was my thought, too. I was going to email you to see if we >> could >> >> >> change all the char* stuff in the stack and interpreter to QStrings? >> >> >> >> >> >> Looking forward to your commit. >> >> >> >> >> >> Jim >> >> >> >> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> >> wrote: >> >> >>> >> >> >>> All, >> >> >>> >> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem was >> >> >>> with the way QStrings were being converted. I have a working >> version >> >> >>> that I'm going to test some more and commit tomorrow. >> >> >>> >> >> >>> -Ian >> >> >>> >> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> >> wrote: >> >> >>> > All, >> >> >>> > >> >> >>> > I believe the reason you're seeing the question marks in the >> output >> >> >>> > is >> >> >>> > because Gnu Flex and Bison, which the basic256 parser is written >> in, >> >> >>> > doesn't support Unicode at all. >> >> >>> > >> >> >>> > There are no simple fixes for this, unfortunately. Here are some >> >> >>> > possibilities: >> >> >>> > >> >> >>> > 1) Encode ALL strings in a program's source code using base64 and >> >> >>> > then >> >> >>> > decode them prior to pushing them onto the operand stack. This >> is >> >> >>> > an >> >> >>> > ugly hack, but right now would be the path of least resistance. >> >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports >> >> >>> > Unicode >> >> >>> > 3) Write a custom parser that supports Unicode. This would be a >> >> >>> > *lot* >> >> >>> > of work, but would be a lot of fun for someone interested in >> >> >>> > learning >> >> >>> > compiler design. >> >> >>> > >> >> >>> > If anyone has any other ideas, please let me know. >> >> >>> > >> >> >>> > -Ian >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> >> wrote: >> >> >>> >> Ian, >> >> >>> >> >> >> >>> >> I am very glad that you have returned to the development >> BASIC256! >> >> >>> >> I >> >> >>> >> would just tell you about a serious problem that exists for >> users >> >> >>> >> who >> >> >>> >> use the Russian language. Attached - screenshot. >> >> >>> >> >> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 for >> >> >>> >> the >> >> >>> >> distribution of ALT Linux. Of course, this patch is not urgent, >> >> >>> >> since >> >> >>> >> you have done a lot of changes. Can I ask you to make necessary >> >> >>> >> changes (because I have little experience) or the provision of >> >> >>> >> Russian-speaking users - only my problem? :-) >> >> >>> >> >> >> >>> >>> On this list about two weeks ago we got a french translation if >> >> >>> >>> anyone >> >> >>> >>> would like to add that in. If not, I'll get around to it >> >> >>> >>> eventually. >> >> >>> >> >> >> >>> >> I have a little more experience, so it's better if you did. >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Blessing, >> >> >>> >> Sergei Irupin >> >> >>> >> http://rnd-lug.blogspot.com/ >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > -- >> >> >>> > My PGP Public Key: >> >> >>> > http://www.scrapshark.com/pubkey.txt >> >> >>> > >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> My PGP Public Key: >> >> >>> http://www.scrapshark.com/pubkey.txt >> >> >>> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > My PGP Public Key: >> >> > http://www.scrapshark.com/pubkey.txt >> >> > >> >> >> >> >> >> >> >> -- >> >> My PGP Public Key: >> >> http://www.scrapshark.com/pubkey.txt >> > >> > >> >> >> >> -- >> My PGP Public Key: >> http://www.scrapshark.com/pubkey.txt >> >> > |
From: james r. <ji...@re...> - 2010-05-02 17:27:03
|
Ian, The U functions do a whole bunch of additional conversion from the char* in utf8 to qstring and then back again to char* utf8. For those of us in the ASCII/English world I thought it would be slower. Havn't done a benchmark. Let me do one before I push. Jim On Sun, May 2, 2010 at 12:51 PM, Ian Larsen <dr...@gm...> wrote: > For the sake of simplicity, why don't you just have your U* functions > just replace the default? For ASCII strings they should do the same > thing as the regular ones. > > -Ian > > On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: > > Guys, > > > > I have gotten the save and load to work with UTF8 and I am adding string > > functions to handle unicode (ULENGTH, USEQ, > UCHR, UMUD, ULEFT, URIGHT, > > UINSTR) and should have them committed later today. > > > > Jim > > > > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> wrote: > >> > >> Here's a screenshot of the result. > >> > >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: > >> > It's even simpler than that. You just have to change most of the > >> > QString::toAscii calls to QString::toUtf8. > >> > > >> > My changes are committed. I've tried to test everything I could but > >> > more extensive testing would ensure I've got everything. If you see > >> > question marks instead of extended characters anywhere, please let me > >> > know. > >> > > >> > -Ian > >> > > >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: > >> >> Ian, > >> >> > >> >> That was my thought, too. I was going to email you to see if we > could > >> >> change all the char* stuff in the stack and interpreter to QStrings? > >> >> > >> >> Looking forward to your commit. > >> >> > >> >> Jim > >> >> > >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> > wrote: > >> >>> > >> >>> All, > >> >>> > >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem was > >> >>> with the way QStrings were being converted. I have a working > version > >> >>> that I'm going to test some more and commit tomorrow. > >> >>> > >> >>> -Ian > >> >>> > >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> > wrote: > >> >>> > All, > >> >>> > > >> >>> > I believe the reason you're seeing the question marks in the > output > >> >>> > is > >> >>> > because Gnu Flex and Bison, which the basic256 parser is written > in, > >> >>> > doesn't support Unicode at all. > >> >>> > > >> >>> > There are no simple fixes for this, unfortunately. Here are some > >> >>> > possibilities: > >> >>> > > >> >>> > 1) Encode ALL strings in a program's source code using base64 and > >> >>> > then > >> >>> > decode them prior to pushing them onto the operand stack. This is > >> >>> > an > >> >>> > ugly hack, but right now would be the path of least resistance. > >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports > >> >>> > Unicode > >> >>> > 3) Write a custom parser that supports Unicode. This would be a > >> >>> > *lot* > >> >>> > of work, but would be a lot of fun for someone interested in > >> >>> > learning > >> >>> > compiler design. > >> >>> > > >> >>> > If anyone has any other ideas, please let me know. > >> >>> > > >> >>> > -Ian > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> > wrote: > >> >>> >> Ian, > >> >>> >> > >> >>> >> I am very glad that you have returned to the development > BASIC256! > >> >>> >> I > >> >>> >> would just tell you about a serious problem that exists for users > >> >>> >> who > >> >>> >> use the Russian language. Attached - screenshot. > >> >>> >> > >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 for > >> >>> >> the > >> >>> >> distribution of ALT Linux. Of course, this patch is not urgent, > >> >>> >> since > >> >>> >> you have done a lot of changes. Can I ask you to make necessary > >> >>> >> changes (because I have little experience) or the provision of > >> >>> >> Russian-speaking users - only my problem? :-) > >> >>> >> > >> >>> >>> On this list about two weeks ago we got a french translation if > >> >>> >>> anyone > >> >>> >>> would like to add that in. If not, I'll get around to it > >> >>> >>> eventually. > >> >>> >> > >> >>> >> I have a little more experience, so it's better if you did. > >> >>> >> > >> >>> >> -- > >> >>> >> Blessing, > >> >>> >> Sergei Irupin > >> >>> >> http://rnd-lug.blogspot.com/ > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > My PGP Public Key: > >> >>> > http://www.scrapshark.com/pubkey.txt > >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> My PGP Public Key: > >> >>> http://www.scrapshark.com/pubkey.txt > >> >>> > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > My PGP Public Key: > >> > http://www.scrapshark.com/pubkey.txt > >> > > >> > >> > >> > >> -- > >> My PGP Public Key: > >> http://www.scrapshark.com/pubkey.txt > > > > > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > > |
From: <web...@bi...> - 2010-05-02 16:57:00
|
All, > I have gotten the save and load to work with UTF8 and I am adding string > functions to handle unicode (ULENGTH, USEQ, UCHR, UMUD, ULEFT, URIGHT, > UINSTR) and should have them committed later today. I think it is not a very good idea. In my opinion, should not create new functions (ULENGTH and etc.), you just need to provide support to utf8 for standard BASIC functions. >> Here's a screenshot of the result. >> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: >> > It's even simpler than that. You just have to change most of the >> > QString::toAscii calls to QString::toUtf8. >> > >> > My changes are committed. I've tried to test everything I could but >> > more extensive testing would ensure I've got everything. If you see >> > question marks instead of extended characters anywhere, please let me >> > know. >> > >> > -Ian >> > >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: >> >> Ian, >> >> >> >> That was my thought, too. I was going to email you to see if we could >> >> change all the char* stuff in the stack and interpreter to QStrings? >> >> >> >> Looking forward to your commit. >> >> >> >> Jim >> >> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: >> >>> >> >>> All, >> >>> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem was >> >>> with the way QStrings were being converted. I have a working version >> >>> that I'm going to test some more and commit tomorrow. >> >>> >> >>> -Ian >> >>> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: >> >>> > All, >> >>> > >> >>> > I believe the reason you're seeing the question marks in the output >> is >> >>> > because Gnu Flex and Bison, which the basic256 parser is written in, >> >>> > doesn't support Unicode at all. >> >>> > >> >>> > There are no simple fixes for this, unfortunately. Here are some >> >>> > possibilities: >> >>> > >> >>> > 1) Encode ALL strings in a program's source code using base64 and >> then >> >>> > decode them prior to pushing them onto the operand stack. This is an >> >>> > ugly hack, but right now would be the path of least resistance. >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports >> Unicode >> >>> > 3) Write a custom parser that supports Unicode. This would be a >> *lot* >> >>> > of work, but would be a lot of fun for someone interested in learning >> >>> > compiler design. >> >>> > >> >>> > If anyone has any other ideas, please let me know. >> >>> > >> >>> > -Ian >> >>> > >> >>> > >> >>> > >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: >> >>> >> Ian, >> >>> >> >> >>> >> I am very glad that you have returned to the development BASIC256! I >> >>> >> would just tell you about a serious problem that exists for users >> who >> >>> >> use the Russian language. Attached - screenshot. >> >>> >> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 for the >> >>> >> distribution of ALT Linux. Of course, this patch is not urgent, >> since >> >>> >> you have done a lot of changes. Can I ask you to make necessary >> >>> >> changes (because I have little experience) or the provision of >> >>> >> Russian-speaking users - only my problem? :-) >> >>> >> >> >>> >>> On this list about two weeks ago we got a french translation if >> anyone >> >>> >>> would like to add that in. If not, I'll get around to it >> eventually. >> >>> >> >> >>> >> I have a little more experience, so it's better if you did. >> >>> >> -- Blessing, Sergei Irupin http://rnd-lug.blogspot.com/ |
From: Ian L. <dr...@gm...> - 2010-05-02 16:51:14
|
For the sake of simplicity, why don't you just have your U* functions just replace the default? For ASCII strings they should do the same thing as the regular ones. -Ian On Sun, May 2, 2010 at 12:45 PM, james reneau <ji...@re...> wrote: > Guys, > > I have gotten the save and load to work with UTF8 and I am adding string > functions to handle unicode (ULENGTH, USEQ, UCHR, UMUD, ULEFT, URIGHT, > UINSTR) and should have them committed later today. > > Jim > > On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> wrote: >> >> Here's a screenshot of the result. >> >> On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: >> > It's even simpler than that. You just have to change most of the >> > QString::toAscii calls to QString::toUtf8. >> > >> > My changes are committed. I've tried to test everything I could but >> > more extensive testing would ensure I've got everything. If you see >> > question marks instead of extended characters anywhere, please let me >> > know. >> > >> > -Ian >> > >> > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: >> >> Ian, >> >> >> >> That was my thought, too. I was going to email you to see if we could >> >> change all the char* stuff in the stack and interpreter to QStrings? >> >> >> >> Looking forward to your commit. >> >> >> >> Jim >> >> >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: >> >>> >> >>> All, >> >>> >> >>> I was wrong about Flex; it handles Utf8 just fine. The problem was >> >>> with the way QStrings were being converted. I have a working version >> >>> that I'm going to test some more and commit tomorrow. >> >>> >> >>> -Ian >> >>> >> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: >> >>> > All, >> >>> > >> >>> > I believe the reason you're seeing the question marks in the output >> >>> > is >> >>> > because Gnu Flex and Bison, which the basic256 parser is written in, >> >>> > doesn't support Unicode at all. >> >>> > >> >>> > There are no simple fixes for this, unfortunately. Here are some >> >>> > possibilities: >> >>> > >> >>> > 1) Encode ALL strings in a program's source code using base64 and >> >>> > then >> >>> > decode them prior to pushing them onto the operand stack. This is >> >>> > an >> >>> > ugly hack, but right now would be the path of least resistance. >> >>> > 2) Find a drop-in replacement for Flex and Bison that supports >> >>> > Unicode >> >>> > 3) Write a custom parser that supports Unicode. This would be a >> >>> > *lot* >> >>> > of work, but would be a lot of fun for someone interested in >> >>> > learning >> >>> > compiler design. >> >>> > >> >>> > If anyone has any other ideas, please let me know. >> >>> > >> >>> > -Ian >> >>> > >> >>> > >> >>> > >> >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: >> >>> >> Ian, >> >>> >> >> >>> >> I am very glad that you have returned to the development BASIC256! >> >>> >> I >> >>> >> would just tell you about a serious problem that exists for users >> >>> >> who >> >>> >> use the Russian language. Attached - screenshot. >> >>> >> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 for >> >>> >> the >> >>> >> distribution of ALT Linux. Of course, this patch is not urgent, >> >>> >> since >> >>> >> you have done a lot of changes. Can I ask you to make necessary >> >>> >> changes (because I have little experience) or the provision of >> >>> >> Russian-speaking users - only my problem? :-) >> >>> >> >> >>> >>> On this list about two weeks ago we got a french translation if >> >>> >>> anyone >> >>> >>> would like to add that in. If not, I'll get around to it >> >>> >>> eventually. >> >>> >> >> >>> >> I have a little more experience, so it's better if you did. >> >>> >> >> >>> >> -- >> >>> >> Blessing, >> >>> >> Sergei Irupin >> >>> >> http://rnd-lug.blogspot.com/ >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > My PGP Public Key: >> >>> > http://www.scrapshark.com/pubkey.txt >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> My PGP Public Key: >> >>> http://www.scrapshark.com/pubkey.txt >> >>> >> >> >> >> >> > >> > >> > >> > -- >> > My PGP Public Key: >> > http://www.scrapshark.com/pubkey.txt >> > >> >> >> >> -- >> My PGP Public Key: >> http://www.scrapshark.com/pubkey.txt > > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: james r. <ji...@re...> - 2010-05-02 16:46:06
|
Guys, I have gotten the save and load to work with UTF8 and I am adding string functions to handle unicode (ULENGTH, USEQ, UCHR, UMUD, ULEFT, URIGHT, UINSTR) and should have them committed later today. Jim On Sat, May 1, 2010 at 5:39 PM, Ian Larsen <dr...@gm...> wrote: > Here's a screenshot of the result. > > On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: > > It's even simpler than that. You just have to change most of the > > QString::toAscii calls to QString::toUtf8. > > > > My changes are committed. I've tried to test everything I could but > > more extensive testing would ensure I've got everything. If you see > > question marks instead of extended characters anywhere, please let me > > know. > > > > -Ian > > > > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: > >> Ian, > >> > >> That was my thought, too. I was going to email you to see if we could > >> change all the char* stuff in the stack and interpreter to QStrings? > >> > >> Looking forward to your commit. > >> > >> Jim > >> > >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: > >>> > >>> All, > >>> > >>> I was wrong about Flex; it handles Utf8 just fine. The problem was > >>> with the way QStrings were being converted. I have a working version > >>> that I'm going to test some more and commit tomorrow. > >>> > >>> -Ian > >>> > >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: > >>> > All, > >>> > > >>> > I believe the reason you're seeing the question marks in the output > is > >>> > because Gnu Flex and Bison, which the basic256 parser is written in, > >>> > doesn't support Unicode at all. > >>> > > >>> > There are no simple fixes for this, unfortunately. Here are some > >>> > possibilities: > >>> > > >>> > 1) Encode ALL strings in a program's source code using base64 and > then > >>> > decode them prior to pushing them onto the operand stack. This is an > >>> > ugly hack, but right now would be the path of least resistance. > >>> > 2) Find a drop-in replacement for Flex and Bison that supports > Unicode > >>> > 3) Write a custom parser that supports Unicode. This would be a > *lot* > >>> > of work, but would be a lot of fun for someone interested in learning > >>> > compiler design. > >>> > > >>> > If anyone has any other ideas, please let me know. > >>> > > >>> > -Ian > >>> > > >>> > > >>> > > >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: > >>> >> Ian, > >>> >> > >>> >> I am very glad that you have returned to the development BASIC256! I > >>> >> would just tell you about a serious problem that exists for users > who > >>> >> use the Russian language. Attached - screenshot. > >>> >> > >>> >> I made a patch for version 0.9.5 which was published 12/2009 for the > >>> >> distribution of ALT Linux. Of course, this patch is not urgent, > since > >>> >> you have done a lot of changes. Can I ask you to make necessary > >>> >> changes (because I have little experience) or the provision of > >>> >> Russian-speaking users - only my problem? :-) > >>> >> > >>> >>> On this list about two weeks ago we got a french translation if > anyone > >>> >>> would like to add that in. If not, I'll get around to it > eventually. > >>> >> > >>> >> I have a little more experience, so it's better if you did. > >>> >> > >>> >> -- > >>> >> Blessing, > >>> >> Sergei Irupin > >>> >> http://rnd-lug.blogspot.com/ > >>> > > >>> > > >>> > > >>> > -- > >>> > My PGP Public Key: > >>> > http://www.scrapshark.com/pubkey.txt > >>> > > >>> > >>> > >>> > >>> -- > >>> My PGP Public Key: > >>> http://www.scrapshark.com/pubkey.txt > >>> > >> > >> > > > > > > > > -- > > My PGP Public Key: > > http://www.scrapshark.com/pubkey.txt > > > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > |
From: Ian L. <dr...@gm...> - 2010-05-01 21:39:50
|
Here's a screenshot of the result. On Sat, May 1, 2010 at 5:34 PM, Ian Larsen <dr...@gm...> wrote: > It's even simpler than that. You just have to change most of the > QString::toAscii calls to QString::toUtf8. > > My changes are committed. I've tried to test everything I could but > more extensive testing would ensure I've got everything. If you see > question marks instead of extended characters anywhere, please let me > know. > > -Ian > > On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: >> Ian, >> >> That was my thought, too. I was going to email you to see if we could >> change all the char* stuff in the stack and interpreter to QStrings? >> >> Looking forward to your commit. >> >> Jim >> >> On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: >>> >>> All, >>> >>> I was wrong about Flex; it handles Utf8 just fine. The problem was >>> with the way QStrings were being converted. I have a working version >>> that I'm going to test some more and commit tomorrow. >>> >>> -Ian >>> >>> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: >>> > All, >>> > >>> > I believe the reason you're seeing the question marks in the output is >>> > because Gnu Flex and Bison, which the basic256 parser is written in, >>> > doesn't support Unicode at all. >>> > >>> > There are no simple fixes for this, unfortunately. Here are some >>> > possibilities: >>> > >>> > 1) Encode ALL strings in a program's source code using base64 and then >>> > decode them prior to pushing them onto the operand stack. This is an >>> > ugly hack, but right now would be the path of least resistance. >>> > 2) Find a drop-in replacement for Flex and Bison that supports Unicode >>> > 3) Write a custom parser that supports Unicode. This would be a *lot* >>> > of work, but would be a lot of fun for someone interested in learning >>> > compiler design. >>> > >>> > If anyone has any other ideas, please let me know. >>> > >>> > -Ian >>> > >>> > >>> > >>> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: >>> >> Ian, >>> >> >>> >> I am very glad that you have returned to the development BASIC256! I >>> >> would just tell you about a serious problem that exists for users who >>> >> use the Russian language. Attached - screenshot. >>> >> >>> >> I made a patch for version 0.9.5 which was published 12/2009 for the >>> >> distribution of ALT Linux. Of course, this patch is not urgent, since >>> >> you have done a lot of changes. Can I ask you to make necessary >>> >> changes (because I have little experience) or the provision of >>> >> Russian-speaking users - only my problem? :-) >>> >> >>> >>> On this list about two weeks ago we got a french translation if anyone >>> >>> would like to add that in. If not, I'll get around to it eventually. >>> >> >>> >> I have a little more experience, so it's better if you did. >>> >> >>> >> -- >>> >> Blessing, >>> >> Sergei Irupin >>> >> http://rnd-lug.blogspot.com/ >>> > >>> > >>> > >>> > -- >>> > My PGP Public Key: >>> > http://www.scrapshark.com/pubkey.txt >>> > >>> >>> >>> >>> -- >>> My PGP Public Key: >>> http://www.scrapshark.com/pubkey.txt >>> >> >> > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: Ian L. <dr...@gm...> - 2010-05-01 21:34:38
|
It's even simpler than that. You just have to change most of the QString::toAscii calls to QString::toUtf8. My changes are committed. I've tried to test everything I could but more extensive testing would ensure I've got everything. If you see question marks instead of extended characters anywhere, please let me know. -Ian On Sat, May 1, 2010 at 4:57 PM, james reneau <ji...@re...> wrote: > Ian, > > That was my thought, too. I was going to email you to see if we could > change all the char* stuff in the stack and interpreter to QStrings? > > Looking forward to your commit. > > Jim > > On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: >> >> All, >> >> I was wrong about Flex; it handles Utf8 just fine. The problem was >> with the way QStrings were being converted. I have a working version >> that I'm going to test some more and commit tomorrow. >> >> -Ian >> >> On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: >> > All, >> > >> > I believe the reason you're seeing the question marks in the output is >> > because Gnu Flex and Bison, which the basic256 parser is written in, >> > doesn't support Unicode at all. >> > >> > There are no simple fixes for this, unfortunately. Here are some >> > possibilities: >> > >> > 1) Encode ALL strings in a program's source code using base64 and then >> > decode them prior to pushing them onto the operand stack. This is an >> > ugly hack, but right now would be the path of least resistance. >> > 2) Find a drop-in replacement for Flex and Bison that supports Unicode >> > 3) Write a custom parser that supports Unicode. This would be a *lot* >> > of work, but would be a lot of fun for someone interested in learning >> > compiler design. >> > >> > If anyone has any other ideas, please let me know. >> > >> > -Ian >> > >> > >> > >> > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: >> >> Ian, >> >> >> >> I am very glad that you have returned to the development BASIC256! I >> >> would just tell you about a serious problem that exists for users who >> >> use the Russian language. Attached - screenshot. >> >> >> >> I made a patch for version 0.9.5 which was published 12/2009 for the >> >> distribution of ALT Linux. Of course, this patch is not urgent, since >> >> you have done a lot of changes. Can I ask you to make necessary >> >> changes (because I have little experience) or the provision of >> >> Russian-speaking users - only my problem? :-) >> >> >> >>> On this list about two weeks ago we got a french translation if anyone >> >>> would like to add that in. If not, I'll get around to it eventually. >> >> >> >> I have a little more experience, so it's better if you did. >> >> >> >> -- >> >> Blessing, >> >> Sergei Irupin >> >> http://rnd-lug.blogspot.com/ >> > >> > >> > >> > -- >> > My PGP Public Key: >> > http://www.scrapshark.com/pubkey.txt >> > >> >> >> >> -- >> My PGP Public Key: >> http://www.scrapshark.com/pubkey.txt >> > > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: james r. <ji...@re...> - 2010-05-01 20:57:14
|
Ian, That was my thought, too. I was going to email you to see if we could change all the char* stuff in the stack and interpreter to QStrings? Looking forward to your commit. Jim On Fri, Apr 30, 2010 at 9:59 PM, Ian Larsen <dr...@gm...> wrote: > All, > > I was wrong about Flex; it handles Utf8 just fine. The problem was > with the way QStrings were being converted. I have a working version > that I'm going to test some more and commit tomorrow. > > -Ian > > On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: > > All, > > > > I believe the reason you're seeing the question marks in the output is > > because Gnu Flex and Bison, which the basic256 parser is written in, > > doesn't support Unicode at all. > > > > There are no simple fixes for this, unfortunately. Here are some > possibilities: > > > > 1) Encode ALL strings in a program's source code using base64 and then > > decode them prior to pushing them onto the operand stack. This is an > > ugly hack, but right now would be the path of least resistance. > > 2) Find a drop-in replacement for Flex and Bison that supports Unicode > > 3) Write a custom parser that supports Unicode. This would be a *lot* > > of work, but would be a lot of fun for someone interested in learning > > compiler design. > > > > If anyone has any other ideas, please let me know. > > > > -Ian > > > > > > > > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: > >> Ian, > >> > >> I am very glad that you have returned to the development BASIC256! I > >> would just tell you about a serious problem that exists for users who > >> use the Russian language. Attached - screenshot. > >> > >> I made a patch for version 0.9.5 which was published 12/2009 for the > >> distribution of ALT Linux. Of course, this patch is not urgent, since > >> you have done a lot of changes. Can I ask you to make necessary > >> changes (because I have little experience) or the provision of > >> Russian-speaking users - only my problem? :-) > >> > >>> On this list about two weeks ago we got a french translation if anyone > >>> would like to add that in. If not, I'll get around to it eventually. > >> > >> I have a little more experience, so it's better if you did. > >> > >> -- > >> Blessing, > >> Sergei Irupin > >> http://rnd-lug.blogspot.com/ > > > > > > > > -- > > My PGP Public Key: > > http://www.scrapshark.com/pubkey.txt > > > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > > |
From: Ian L. <dr...@gm...> - 2010-05-01 01:59:26
|
All, I was wrong about Flex; it handles Utf8 just fine. The problem was with the way QStrings were being converted. I have a working version that I'm going to test some more and commit tomorrow. -Ian On Fri, Apr 30, 2010 at 5:53 PM, Ian Larsen <dr...@gm...> wrote: > All, > > I believe the reason you're seeing the question marks in the output is > because Gnu Flex and Bison, which the basic256 parser is written in, > doesn't support Unicode at all. > > There are no simple fixes for this, unfortunately. Here are some possibilities: > > 1) Encode ALL strings in a program's source code using base64 and then > decode them prior to pushing them onto the operand stack. This is an > ugly hack, but right now would be the path of least resistance. > 2) Find a drop-in replacement for Flex and Bison that supports Unicode > 3) Write a custom parser that supports Unicode. This would be a *lot* > of work, but would be a lot of fun for someone interested in learning > compiler design. > > If anyone has any other ideas, please let me know. > > -Ian > > > > On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: >> Ian, >> >> I am very glad that you have returned to the development BASIC256! I >> would just tell you about a serious problem that exists for users who >> use the Russian language. Attached - screenshot. >> >> I made a patch for version 0.9.5 which was published 12/2009 for the >> distribution of ALT Linux. Of course, this patch is not urgent, since >> you have done a lot of changes. Can I ask you to make necessary >> changes (because I have little experience) or the provision of >> Russian-speaking users - only my problem? :-) >> >>> On this list about two weeks ago we got a french translation if anyone >>> would like to add that in. If not, I'll get around to it eventually. >> >> I have a little more experience, so it's better if you did. >> >> -- >> Blessing, >> Sergei Irupin >> http://rnd-lug.blogspot.com/ > > > > -- > My PGP Public Key: > http://www.scrapshark.com/pubkey.txt > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: Ian L. <dr...@gm...> - 2010-04-30 21:53:09
|
All, I believe the reason you're seeing the question marks in the output is because Gnu Flex and Bison, which the basic256 parser is written in, doesn't support Unicode at all. There are no simple fixes for this, unfortunately. Here are some possibilities: 1) Encode ALL strings in a program's source code using base64 and then decode them prior to pushing them onto the operand stack. This is an ugly hack, but right now would be the path of least resistance. 2) Find a drop-in replacement for Flex and Bison that supports Unicode 3) Write a custom parser that supports Unicode. This would be a *lot* of work, but would be a lot of fun for someone interested in learning compiler design. If anyone has any other ideas, please let me know. -Ian On Fri, Apr 30, 2010 at 11:06 AM, <web...@bi...> wrote: > Ian, > > I am very glad that you have returned to the development BASIC256! I > would just tell you about a serious problem that exists for users who > use the Russian language. Attached - screenshot. > > I made a patch for version 0.9.5 which was published 12/2009 for the > distribution of ALT Linux. Of course, this patch is not urgent, since > you have done a lot of changes. Can I ask you to make necessary > changes (because I have little experience) or the provision of > Russian-speaking users - only my problem? :-) > >> On this list about two weeks ago we got a french translation if anyone >> would like to add that in. If not, I'll get around to it eventually. > > I have a little more experience, so it's better if you did. > > -- > Blessing, > Sergei Irupin > http://rnd-lug.blogspot.com/ -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt |
From: <web...@bi...> - 2010-04-30 15:06:41
|
Ian, I am very glad that you have returned to the development BASIC256! I would just tell you about a serious problem that exists for users who use the Russian language. Attached - screenshot. I made a patch for version 0.9.5 which was published 12/2009 for the distribution of ALT Linux. Of course, this patch is not urgent, since you have done a lot of changes. Can I ask you to make necessary changes (because I have little experience) or the provision of Russian-speaking users - only my problem? :-) > On this list about two weeks ago we got a french translation if anyone > would like to add that in. If not, I'll get around to it eventually. I have a little more experience, so it's better if you did. -- Blessing, Sergei Irupin http://rnd-lug.blogspot.com/ |
From: Ian L. <dr...@gm...> - 2010-04-25 23:37:29
|
All, I've committed my changes to the trunk, so all should be good now. I'm going to delete my branch. I made a few commits within minutes of each other to fix a small bug preventing the gcc build, but all's well now and I've tested in Ubuntu (GCC) and Windows (Visual Studio). I've broken the command line arguments, but I'll try to fix those tonight. Visual Studio doesn't have the gnu getopt library which I used to parse the args, so I'll make some changes to the windows version to fix that. I've changed the way the operand stack works; it now allocates a block of memory for an actual stack (previously used a linked list of stack frames) and resizes it as necessary. This provides a 2-3 times speedup in some programs, and should eliminate a huge potential class of memory handling errors. If you run the mandelbrot.kbs example you'll see a huge difference in the performance. It looks like there might be some problems with the basicParse.y file with order of operations. It also contains some shift/reduce conflicts that I aim to fix next. On this list about two weeks ago we got a french translation if anyone would like to add that in. If not, I'll get around to it eventually. -Ian |