October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Glorp + NBSQLite3

by Esteban A. Maringolo

Sanjay-M <sm(a)planage.com> wrote: > I was wondering if this approach could be adopted in developing a > Client/Server application with a separate server component accessing the > SQLite database (on a separate machine). > If a template / model can be developed i am sure this can be very useful in > creating larger multi-user applications even at the cost of some duplication > / redundant effort. > I am thinking of situations where we cannot have a web server even on the > intranet - more like traditional servers accessed over TCP/IP Sorry but I can't follow your question. SQLite is a file based RDBMS engine, designed to be accessed locally and not through TCP/IP. If what you need to do is run over a network PostgreSQL will provide you with such feature (plus a lot others). Remember: âSQLite is not a replacement for PostgreSQL [or any other RDBMS]. SQLite is a replacement for fopen().â Regards. Esteban A. Maringolo

Oct. 6, 2014

Re: [Pharo-users] Glorp + NBSQLite3

by Sanjay-M

I am thinking of situations where we cannot have a web server even on the intranet - more like traditional servers accessed over TCP/IP ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/Glorp-NBSQLite3-tp4779996p4782972.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 6, 2014

Re: [Pharo-users] Glorp + NBSQLite3

by Pierce Ng

On Fri, Oct 03, 2014 at 09:19:15PM -0700, Sanjay-M wrote: > I was wondering if this approach could be adopted in developing a > Client/Server application with a separate server component accessing the > SQLite database (on a separate machine). Using HTTP/S as the client-server protocol, have the web app server manage data persistence, be it SQLite, GOODS or Gemstone, ...? Pierce

Oct. 6, 2014

Re: [Pharo-users] Glorp + NBSQLite3

by Pierce Ng

On Fri, Oct 03, 2014 at 10:44:43PM +0200, stepharo wrote: > Cool what is NBSQLite3 (a nativeboost version)? Nice. Would be nice > once you API stabilize that we get a chapter or on NBSQLite3 :) Yes, NativeBoost interface to SQLite. Yes, I plan to write a chapter on it. :-) Pierce

Oct. 6, 2014

Re: [Pharo-users] Android VM update

by kilon alios

cant wait to test this on android , hope it becomes available via play store :) On Mon, Oct 6, 2014 at 12:57 PM, Annick Fron <list(a)afceurope.com> wrote: > Hi, > > Should I load the new versions of FFI and Alien as well ? from September > 30th ? > > Annick > > Le 6 oct. 2014 Ã 11:30, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> > a Ã©crit : > > Hi, > I just comeback from holiday, and I realise that I do not have done a > announcement yet. > Now the prototype of the Pharo Android VM work. > - Event is managed > - Resolution up to 1080p is managed. > - Most of the plugins seems worked. > - File plugin allow you to browse the sd card. > Next: > - fix the generator then jenkins. Merge with Pharo/Cog main and Make it > available for the public. > - die under the mountain of bug entry open by the first public release. First > release will be perfect and bugless. > - allow easy personalisation of the packaging, allow you to rename and > change icon easily (for your own application, Squeak/Pharo Android VM, > Phratch, DR geo, etc.). > - refined the jumpout logic for have a better graphical update and a > better idle process (less consumption, faster reactive UI, UI updating > during heavy computation, etc. ). > - package the android feature in the android plugin, show/hide the > keyboard via primitive, etc. etc. + init configuration. > - a lot of cool idea but later > > Here is a youtube video to show the result: > http://youtu.be/lB9UV9Z7Kss > > You can forward this to other mailing list, I do not have access to all of > them. > > Best Regards > Dr Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > >

Oct. 6, 2014

Re: [Pharo-users] Android VM update

by Annick Fron

Hi, Should I load the new versions of FFI and Alien as well ? from September 30th ? Annick Le 6 oct. 2014 Ã 11:30, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> a Ã©crit : > Hi, > I just comeback from holiday, and I realise that I do not have done a announcement yet. > Now the prototype of the Pharo Android VM work. > - Event is managed > - Resolution up to 1080p is managed. > - Most of the plugins seems worked. > - File plugin allow you to browse the sd card. > Next: > - fix the generator then jenkins. Merge with Pharo/Cog main and Make it available for the public. > - die under the mountain of bug entry open by the first public release. First release will be perfect and bugless. > - allow easy personalisation of the packaging, allow you to rename and change icon easily (for your own application, Squeak/Pharo Android VM, Phratch, DR geo, etc.). > - refined the jumpout logic for have a better graphical update and a better idle process (less consumption, faster reactive UI, UI updating during heavy computation, etc. ). > - package the android feature in the android plugin, show/hide the keyboard via primitive, etc. etc. + init configuration. > - a lot of cool idea but later > > Here is a youtube video to show the result: > http://youtu.be/lB9UV9Z7Kss > > You can forward this to other mailing list, I do not have access to all of them. > > Best Regards > Dr Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > >

Oct. 6, 2014

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Damien Cassou

On Thu, Oct 2, 2014 at 8:43 PM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > BTW: Is there any guide regarding the kind of language (e.g. tonality) of > the book. I'd change the it given the fact that the blog entry is pretty > informal which is IMHO not appropriate for a book ... no such guide exist. Do your best and we will do another pass on it afterwards. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 6, 2014

Android VM update

by Jean Baptiste Arnaud

Hi, I just comeback from holiday, and I realise that I do not have done a announcement yet. Now the prototype of the Pharo Android VM work. - Event is managed - Resolution up to 1080p is managed. - Most of the plugins seems worked. - File plugin allow you to browse the sd card. Next: - fix the generator then jenkins. Merge with Pharo/Cog main and Make it available for the public. - die under the mountain of bug entry open by the first public release. First release will be perfect and bugless. - allow easy personalisation of the packaging, allow you to rename and change icon easily (for your own application, Squeak/Pharo Android VM, Phratch, DR geo, etc.). - refined the jumpout logic for have a better graphical update and a better idle process (less consumption, faster reactive UI, UI updating during heavy computation, etc. ). - package the android feature in the android plugin, show/hide the keyboard via primitive, etc. etc. + init configuration. - a lot of cool idea but later Here is a youtube video to show the result: http://youtu.be/lB9UV9Z7Kss You can forward this to other mailing list, I do not have access to all of them. Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

Oct. 6, 2014

Re: [Pharo-users] Spur images

by Benjamin Pollack

On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Working with WideStrings is way slower than working with ByteStrings, > there is just no way around that. What is especially slow is the > automagic switch from ByteString to WideString, for example in a > String>>#streamContents: because a #becomeForward: is involved. If that > happens for every line or every token, that would be crazy. > > Apart from that, the tokenisation is not very efficient, #lines is a > copy of your whole contents, so is the #split: and #trimmed. The > algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye > for performance might yield better results. > > But I guess this is not really an exercise in optimisation. If it is, > you should give us the dataset and code (and maybe runnable python code > as reference), with some comments. Meh, optimizing the languages maybe, but not the code. The Python code I'm comparing against (and the "sane" C++ code I keep around, for that matter) makes these exact same decisions in the interest of readability. Indeed, the equivalent from my Python code for that line is with open(path) as f: lines = [[word.strip() for word in line.split(',')] for line in f] This does avoid loading the whole into RAM just to split it, but is otherwise identical (i.e., strip() allocates an extra string, split() allocates lots of extra strings, and the list comprehension is analogous to the #collect: call, etc.), so it seems a fair comparison to me. If you're curious, the maximum speed I've been able to get out of a carefully crafted, but not unreadable, C that simply passes around a bunch of (start, stop) tuples, rather than strings, comes down to about 40ms. I know I can get better than that, but I lost interest in rewriting all the string routines. I figure another 10ms-20ms could come off, at which point it'd finally be as much I/O bound as anything else. --Benjamin

Oct. 5, 2014

Re: [Pharo-users] Spur images

by Sven Van Caekenberghe

Hi Benjamin, On 05 Oct 2014, at 22:37, Benjamin Pollack <benjamin(a)bitquabit.com> wrote: > On Sun, 05 Oct 2014 10:36:31 -0400, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> How come you got WideStrings ? >> What does the input look like, can you give a partial example ? > > I'm guessing I got WideStrings because the file is indeed in UTF-8, with lots of characters outside the lower 128 code points. A sample couple of lines might look like > > åç°åº·å¸,The National,Sarah McLachlan,å¨æ°å«,Indochine,Rise Against,City and Colour,CÃ¦cilie Norby,El Cumbanchero,Death Letter > The Beatles,The Who,Barenaked Ladies,The Doors,Bob Dylan > > These are two play lists, one per line; each comma-delimited element is a band on that play list. > > The full line for reading and tokenization is just "pathToFile asFileReference contents lines collect: [ :line | (',' split: line) collect: [ :ea | ea trimmed ]]." Based on the profile indicating that a lot of time is lost on things like WideString>>copyFrom:to:, I wasn't optimistic about trying to stream the contents instead of just calling "contents lines", but I admit I didn't try. > > --Benjamin Working with WideStrings is way slower than working with ByteStrings, there is just no way around that. What is especially slow is the automagic switch from ByteString to WideString, for example in a String>>#streamContents: because a #becomeForward: is involved. If that happens for every line or every token, that would be crazy. Apart from that, the tokenisation is not very efficient, #lines is a copy of your whole contents, so is the #split: and #trimmed. The algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye for performance might yield better results. But I guess this is not really an exercise in optimisation. If it is, you should give us the dataset and code (and maybe runnable python code as reference), with some comments. Sven

Oct. 5, 2014