- Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

Keep in mind that Monticello is "portable" to other dialects and changing the internal representation will break Monticello for other platforms ... FWIW, the implemenation of OrderedCollection in GemStone is very different than in Pharo or Squeak and it was possible for me to fudge the serializer to do the right thing for Monticello (which was serialize the OrderedCollections the way Pharo/Squeakl expected)... A similar thing could be done for Pharo if you wanted to change the shape of OrderedCollection... Dale On Fri, Sep 19, 2014 at 5:06 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-09-19 13:55 GMT+02:00 Markus Fritsche <mfritsche(a)reauktion.de>: > >> On 2014-09-19 11:35, Max Leske wrote: >> >> - 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). >>> >> >> I might be a bit fundamentalistic, but shouldn't this (a using class >> making assumptions about the objects it's using) be considered a bug >> by object oriented standards? >> >> Best regards >> Markus >> >> > It's not the using class per se. > It's that MC is using a serialization framework sensitive to internal > object representation (number/order of ivars). > The question is this one: > - would using FUEL would have resolved the problem or not? > - wouldn't a serialization using message sends to reconstruct the objects > be more robust (future proof)? > Of course the later requires the maintenance of a well defined API, so the > robstness is relative. > But at least, it would respect the object paradigm a bit more. > > Nicolas >

Sept. 19, 2014

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

by stepharo

max why not subclassing OrderedCollections? > 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 you initialize to nil first? > 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. > > 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 >

Sept. 19, 2014

[ANN] ExternalTools for *nix - edit w/ $EDITOR and open pictures

by phil＠highoctane.be

I had enough to switch between windows to work on external files. So, here is ExternalTools It adds some commands to the File Browser, allowing one to edit in the $EDITOR (for me this is gvim) and another thing for opening the file externally through xdg-open (which kind of opens about anything). Basically, one can extend this to whatever is needed. The only thing is that FileServices initialize needs to be called when a new service is added if you create your own. This is Unix only and requires OSProcess to be loaded (use the ConfigurationBrowser). Gofer it url: 'http://www.smalltalkhub.com/mc/philippeback/HOExtras/main'; package: 'HighOctane-Tools'; load. Screenshot in attach. Doc here: https://gist.github.com/philippeback/8e8f8c6685bebf47f53f Phil

Sept. 19, 2014