September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Review: 11536] Add Stream >> printString:

by Esteban A. Maringolo

2014-09-19 20:59 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> This issue was more of a discussion between Camillo and Sven. They never >> reached a conclusion, so please take a look. Iâve compiled the transcript >> below. >> >> The issue isnât easy to solve and maybe we can just close it as ânot >> importantâ. > > > +1. But isn't the selector printString: broken? The selector sounds broken to me too. I always bring Dolphin to the discussion, but Dolphin streams had both #print:/#display: WriteStream>>#print: anObject anObject printOn: aStream. WriteStream>>#display: anObject anObject displayOn: aStream. But those are for printing/displaying the argument on the stream, which is not exactly the same as sending #asString and then then appending the result to receiver. So Eliot's #printAsString: seems to be the most intention revealing selector for such task. Regards!

Sept. 20, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by phil＠highoctane.be

Le 20 sept. 2014 02:11, "Alain Rastoul" <alf.mmm.cat(a)gmail.com> a Ã©crit : > > Le 15/09/2014 18:23, Eliot Miranda a Ã©crit : > >> I find this whole discussion depressing. It seems people would rather >> put their energy in chasing quick fixes or other technologies instead of >> contributing to the work that is being done in the existing VM. People >> discuss using LLVM as if the code generation capabilities inside Cog >> were somehow poor or have no chance of competing. Spur is around twice >> as fast as the current memory manager, has much better support for the >> FFI. ClÃ©ment and I, now with help from Ronie, are making excellent >> progress towards an adaptive optimizer/speculative inliner that will >> give us similar performance to V8 (the Google JavaScript VM, lead by >> Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. >> We are trying to get person-power for a high-quality FFI and have a >> prototype for a non-blocking VM. When we succeed C won't be any better >> and so it won't be an interesting target. One will be able to program >> entirely in Smalltalk and get excellent performance. But we need >> effort. Collaboration. > > > Hi Eliot, > > Not everybody has the necessary skills to help and contribute to your work, my assembly skills are really faraway and outdated now (... little frustration here :( ... ) > but imho your work is unvaluable to pharo and smalltalk community > - just to mention it, I noticed a 30 to 50% gain in a small bench I wrote for fun recently (a very dumb chess pawn moves generator) with the last Spur vm > I was shocked :) > 64bits + x2 perfs + non blocking (or multi threaded?) vm are giant steps forward > that makes it possible for pharo smalltalk to compete with mainstream technologies We'll prevail! What we also need to do is to showcase the Smalltalk workflow and how nice it is. We cannot gain mindshare by technical prowess only. Phil > > Regards, > > Alain > >

Sept. 20, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Alain Rastoul

Le 15/09/2014 18:23, Eliot Miranda a Ã©crit : > I find this whole discussion depressing. It seems people would rather > put their energy in chasing quick fixes or other technologies instead of > contributing to the work that is being done in the existing VM. People > discuss using LLVM as if the code generation capabilities inside Cog > were somehow poor or have no chance of competing. Spur is around twice > as fast as the current memory manager, has much better support for the > FFI. ClÃ©ment and I, now with help from Ronie, are making excellent > progress towards an adaptive optimizer/speculative inliner that will > give us similar performance to V8 (the Google JavaScript VM, lead by > Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. > We are trying to get person-power for a high-quality FFI and have a > prototype for a non-blocking VM. When we succeed C won't be any better > and so it won't be an interesting target. One will be able to program > entirely in Smalltalk and get excellent performance. But we need > effort. Collaboration. Hi Eliot, Not everybody has the necessary skills to help and contribute to your work, my assembly skills are really faraway and outdated now (... little frustration here :( ... ) but imho your work is unvaluable to pharo and smalltalk community - just to mention it, I noticed a 30 to 50% gain in a small bench I wrote for fun recently (a very dumb chess pawn moves generator) with the last Spur vm I was shocked :) 64bits + x2 perfs + non blocking (or multi threaded?) vm are giant steps forward that makes it possible for pharo smalltalk to compete with mainstream technologies Regards, Alain

Sept. 20, 2014

Re: [Pharo-dev] [Review: 11536] Add Stream >> printString:

by Eliot Miranda

On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske(a)gmail.com> wrote: > This issue was more of a discussion between Camillo and Sven. They never > reached a conclusion, so please take a look. Iâve compiled the transcript > below. > > The issue isnât easy to solve and maybe we can just close it as ânot > importantâ. > +1. But isn't the selector printString: broken? Shouldn't it be printAsString: ? > > https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printString > > > ============ > > Camillo: > This method should be added to avoid many asString sends. > > Example: > stream nextPutAll: #('ABC') asString could be written as stream > printString: #('ABC'). > > This is a common extension of the following pattern: > stream nextPutAll: #('ABC') printString could be written as stream print: > #('ABC'). > > > ============ > Sven: > And what about #print: as implemented by Transcripts and SocketStreams ? > > It is shorter. > Feels more familiar. > > > ============ > Camillo: > #print: is already implement and doesn't solve the stream nextPutAll: foo > asString case. Since you cannot simply write stream print: foo, since you > get quotes added for Strings. > > Ok, I admit that with decent design you can avoid this, since it should > almost never happen that you have a String or a non string object in the > same variable, right? > > > ============ > Sven: > Yeah, that String issue is a bit annoying sometimes. > Indeed there is Stream>>#print: already. > > But look: > > ThreadSafeTranscript>>#print: anObject > > self nextPutAll: anObject asString > > > how about that ? > > There is also #<< whose implementation is even weirder, but it is handy. > > The question remain: when do you want to mix Strings and other objects as > arguments ? > > > ============ > Camillo: > - #<< is basically a lazy combination of #nextPut: and #nextPutAll: > - #print: should call #printOn: on the initial argument, which for strings > defaults to storeOn: which I think is wrong, but I would hardly stand a > chance changing that :P > > So my global goal here is to avoid any kind of asString sends while > pushing stuff on a stream. Sadly this happens more often than I thought :/ > > > ============ > Sven: > Maybe this discussion should happen on the mailing list ? > > Changing String>>#printOn: might be hard, but #<< is much more recent, no > ? Could it not be changed to do what you want ? Like > > Streamm>><< anObject > self nextPutAll: anObject asString > > Another point is that #asString is not so efficient, since it creates > throwaway Strings. > -- best, Eliot

Sept. 19, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Alain Rastoul

Le 15/09/2014 14:21, kilon alios a Ã©crit : > thanks I am looking at it > > is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern > Hi, Of course, the only difference between what you will find in java,dotNet,c++ examples and Smalltalk is that the latter does not support method signature because of it's typeless feature and you will have to define different methods. The smalltalk equivalent of (java code) void visit(Wheel wheel); void visit(Engine engine); void visit(Body body); void visit(Car car); would be the following methods: visitWheel: aWhell visitEngine: anEngine visitBody: aBody visitCar: aCar A small disadvantage, but everything has a price ... :) If you are interested in object patterns, you should buy the GOF book http://en.wikipedia.org/wiki/Design_Patterns It's a must have and it's smalltalk companion too http://www.amazon.fr/The-Design-Patterns-Smalltalk-Companion/dp/0201184621 see chapters here: http://stephane.ducasse.free.fr/FreeBooks/SmalltalkDesignPatternCompanion/ Regards, Alain

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Alain Rastoul

Le 19/09/2014 23:36, Torsten Bergmann a Ã©crit : > Hi Sebastian, > I think there are two ways for ODBC'ing from Pharo: > 1. one is the one included in DBXTalk, I think I had this running also > in the past and added > the glorp adaptor for ODBC. Cant remember why I switched to 2. The same for me :) About Glorp, it is a really nice piece of code, but has some drawbacks (like all orms): IIRC, there is a "global" object cache and Glorp manage object's locking conflicts in addition to Sql locking (imho bad). ORM is perfect for quick and simple queries but tend to write bad queries when complex. > 2. the ODBC package (on top of FFI) that you can load from the Config > browser in Pharo 3.0 > This one is based on the ODBC known from Squeak > (http://wiki.squeak.org/squeak/2480) > > Try it with the second first. You have to open the ODBC settings panel > in Windows first, > and then connect to the DB by creating a system wide DSN name > similar to what is explained here for Oracle: > http://www.rpi.edu/datawarehouse/dw-brio-oce-stu-prod.html > > You have to choose the correct MSSQL server driver. Then use this name > for the connection in Smalltalk. > If the connection fails try with a database viewer tool first. > > In detail: > 1. Use a new Pharo 3.0 as from the website first. > 2. Install "ODBC" from the config browser (this will install > requirements like FFI automatically) > 3. Install "OSWindows" from config browser > 4. Evaluate > WinControlPanel showODBCSettings > to open the ODBC panel > 5. Click on the "System DSN" tab there > 6. Click "Add" > 7. Select the SQL Server driver (usually "SQL Server Native Client > blah"), click Next > 8. Enter an unused DSN name like "MYAPP_DB", also enter the IP > address (xxx.xxx.xxx.xxx) > of the server and go Next (no need for port as SQLServer usually > runs on 1433) > 9. Authentication depends on installation. Usually one uses the SQL > Server authentication, either with > a dedicated user connection administrated in SQL Server Tools or > by default the user is something > with "sa" (for system administrator) > 10. After login you should be able to select the database and test > connection right in the ODBC control panel > 11. Go back to Pharo and run some query: > | con results | > Transcript open. > con := ODBCConnection dsn:'MY_SYSTEM_DSN_NAME' user: 'db_user' password: > 'secretOne'. > results := (con query: 'select * from MyApp.dbo.MyTable') execute. > results do:[:row | Transcript show: row; cr]. > con close. > > Try the query with a database tool first. If the query works from ST you > can either use this or try your luck > with DBXTalk and ODBC. Hope this helps. > Bye > T. Perfectly correct, I would also add: 1) On windows, it's simpler to connect to a server without registering a DSN, you can specify the driver to use with odbc, it will find it in the registry. For example, using the MS driver, you specify Driver={SQL Server}; in the connection string (don't remember for oracle but it can work the same way), with other attributes like server name, instance name (if any) ,user , password and so on. You can take a look in the registry to find installed drivers on your pc. There is a class method on ODBCConnection that do the job: toSqlServer:database:.... And you can define your own if you need. Example: ODBCConnection toSqlServer: 'MyServer\MyInstance' database: 'AdventureWorks' applicationId: 'MyApp' workstationId: 'LOCALST' user: 'MyUser' password: 'MyPassord' Using sa in an application is considered bad practice : a huge security breach and dangerous for your sql server. 2) On windows, you don't need to specify the IP address, the network resolution will find it for you. If you use tcp sockets, the sql browser service has to be started, it will handle port resolution for you, you just specify the server and instance name (if any). 3) to use windows authentication, you don't specify user and password but have to add a SSPI=true attribute (not sure, you should rtfm... al...zheimer?). Your windows user is already defined as a sql login, but you have to map it to a windows user in your database and the sql server have to accept sql and windows authentication. 4) For production system, you *may* experience severe locking problems, because the Pharo vm is single threaded. That is the only big problem actually. you may also lock yourself between to connections (not a sql deadlock, we could call it a vm deadlock ...). Apart of the last one, odbc/ffi works like a charm and is very fast. HTH Alain

Sept. 19, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Martin McClure

On 09/16/2014 06:34 AM, ClÃ©ment Bera wrote: > The book that explains the best how to implement a high performance VM > for Smalltalk and why is Urs Holzle phd > <http://www.cs.ucsb.edu/~urs/oocsb/self/papers/urs-thesis.html>. Agreed. This is good (almost required) reading for anyone who wants to understand how to implement dynamic languages in a way that is not slow, and to understand why performance of dynamic languages does not need to be much slower than that of statically-typed languages. After reading this paper, it's also good to think about the fact that it describes work that was done over 20 years ago, and that hardware has changed a great deal in the interim, and think hard about what improvements might be made today over the techniques that Urs and the Self team came up with back then. Regards, -Martin

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Torsten Bergmann

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Alain Rastoul

Le 19/09/2014 13:36, Sebastian Sastre a Ã©crit : > yes if things where in markdown friendly wiki and git you'll see a pull request in half a second > > I'll think of something > > but returning to the dll issue, you mention you endd up using odbc and I see there are two backends to choose from. The odbc and the mssql, so, i'm getting this right? If I use odbc that dll is not needed? > > Any reason not to use odbc? > > from iPad > Hi, libsybdb.dll is for sybase, it may have worked well with (very) old versions of sql server but is definitely not the correct way to connect to MS sql server (*plus MS has it's own version of dblib.dll). (*plus I'm not sure that deploying sybase native libs is legal). The MS recommendations for client connectivity to Sql server is not to use native libraries but instead use a "standard" layer. it's a long story, but to make it short odbc seems to be the best choice once again: MS preconizations: odbc, then rdo, then dao, then oledb, then ado, (and ado.net) and finally odbc again (on top of sql native client) with ado.net for dotnet. see http://msdn.microsoft.com/en-us/data/aa937732 http://msdn.microsoft.com/en-us/library/ms810810.aspx I don't know how it works with opendbx, but odbc is quite solid, and you don't have to take care of native libs deployment. IMHO a good choice Regards Alain

Sept. 19, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Eliot Miranda

On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxleske(a)gmail.com> wrote: > Iâve written an implementation of lazily initialized expandable > collections (for OrderedCollection and subclasses only for now), inspired > by Alexandreâs talk at ESUG ( > http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw) > The implementation is pretty much straight forward but there are a couple > of culprits I want to point out in case anybody else wants to do this: > > - my implementation requires an extra instance variable in > OrderedCollection to store the requested size. This extra instance variable > will break Monticello (and possibly other tools) because Monticello uses > OrderedCollections to load code and the particular way it uses them makes > it impossible to change the number of instance variables on > OrderedCollection. Also, all .mcz files written after the change will not > be loadable by images without the new instance variable (same reason). > - the above means that you have to modify the code in the image manually > and save a new âbase image" > - read only messages should obviously not initialize the array. The > âfirstIndexâ and âlastIndexâ variables are quite handy for that. I > initialize those variables to 1 and 0 respectively which makes most things > work already (e.g. #size, #isEmpty etc.). > - when trying to implement the same for HashedCollection I couldnât. The > image didnât just stop working, there was no output at all on the console, > not even when using a debug VM. The problem seems to be MethodDictionary, > at least thatâs the only subclass of Dictionary for which adding an > instance variable doesnât work. > Yes, alas the shape of MethodDIctionary is baked into the VM's method lookup code. It would be straight-forward to fix it, but it is still work and one would have to wait for people to update their VMs. Iâll share some memory monitoring as soon as I have something significant > (only just rolled it out). > > > Big thanks to Alex for his talk and the cool work he and his students did! > > Cheers, > Max > -- best, Eliot

Sept. 19, 2014