December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI is broken in Cog - success^2 [WAS] Re: Pharo 1.3 vs 1.2.1 some results for ConfigurationOfODBC - success

by Mariano Martinez Peck

Excellent. Thanks for not giving up and for writing such a nice post :) On Thu, Dec 15, 2011 at 5:59 PM, Ben Coman <btc(a)openinworld.com> wrote: > ** > > I am happy to report that Pharo 1.3 ODBC is now working on MS Windows 7 > using CogVM version 2522. > > With the right parts it is straight forward to set up, but for a wider > audience I have detailed the steps at > http://blog.openinworld.com/2011/12/pharo-odbc-working-on-windows-7/ > > cheers, Ben > > Mariano Martinez Peck wrote: > > > > On Wed, Dec 14, 2011 at 5:10 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> That works great. Thanks Mariano. Since I got the file direct from you I >> have uploaded it to [2] in case it is of use to others. >> >> I see the file you provide is "Pharo-1.3-13307-OneClickWin.zip" has many >> more dlls than the file of the same name from INRIA>Files [1]. Is this a >> fix that can be added by a user to the released Pharo-1.3-13315, or >> otherwise be flagged to go into a possible Pharo-1.3.1 ? >> >> I was exploring the load sequence and it was interesting to discover that >> in a fresh image, after... >> > Gofer new >> > squeaksource: 'ODBC'; >> > package: 'ConfigurationOfODBC'; load. >> > (Smalltalk at: #ConfigurationOfODBC) load. >> >> ..."listLoadedModules" did not show odbc32. This only appeared after >> executing... >> > connection := ODBCConnection dsn: 'TestMDB' user: '' password: ''. >> >> That is cool seeing the dynamic nature of plugin loading. Now while you >> will already be aware of the difference between your supplied file [2] and >> the one from [1], for my own learning attempt it would seem from >> "SmalltalkImage current listLoadedModules" that the difference is... >> SqueakFFIPrims VMMaker-oscog.54 (e) working >> versus >> SqueakFFIPrims VMMaker-oscog-IgorStasenko.123 (e) not working. >> ... and unfortunately there is no version information on odbc32. >> > > Yes, the zip I provided you is a CogVM one click I did myself for windows > because the default is not working. It was always a mess for me. I didn't > even remember what I did to make it work. I think I took the SqueakFFI dll > from an older Cog VM or from the one build by Jenkins or something like > that. Until I make it work. But out of the box, the FFI is not working. > > Maybe it has been fixed. You can try the very last VM of Eliot (since > there is no Jenkins for Windows yet) > http://www.mirandabanda.org/files/Cog/VM/VM.r2522/cogwin.zip > > is it working? > > >> >> A side comment for whoever maintains ConfigurationOfODBC... I wonder if >> this could be made to fail earlier - at the "(Smalltalk at: >> #ConfigurationOfODBC) load" rather than waiting for the first attempt at a >> connection. I think logically proving access to the external library >> should be part of the package load. This would help isolate such issues for >> users new to the package. I notice that after a SaveAndExit and restart, >> the odbc plugin is no longer shown in "listLoadedModules" until dynamically >> reloaded on next use of "ODBCconnection". This would remain the standard >> behaviour after proving access to the library for the first time during the >> package load. >> > > +1 > > >> >> [1] https://gforge.inria.fr/frs/?group_id=1299&release_id=6364 >> [2] >> http://files.openinworld.com/Pharo-1.3-13307-OneClickWin-ODBC-thx-Mariano.z… >> >> cheers, Ben >> >> Mariano Martinez Peck wrote: >> >> >> >> On Tue, Dec 13, 2011 at 11:50 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Thanks, but nothing is attached. >>> >> >> Sorry, here it is. >> >> >>> Also, I'm not sure how to "make sure odbc libraries are findable by >>> Windows." >>> >> >> odbc.dll and friends should be in a place where Windows search dlls. I >> think you won't have a problem since Windows usually puts such library in >> its correct place. >> >> >>> Nothing is changed in the environment between running 1.2.1 and 1.3. >>> >>> btw, I've been reading your blog on building the VM, and you indicated >>> you would welcome feedback on english grammar. Here in one and a typo... >>> http://marianopeck.wordpress.com/2011/04/ >>> 1. "as you can image" >> "as you can imagine" >>> 2. "wolrd" >> "world" >>> >>> >> Thanks, I have just integrated them. >> >> >>> cheers, Ben >>> >>> >>> >>> Mariano Martinez Peck wrote: >>> >>> Hi. Just as a test, would you like to test the attached VM? change xxx >>> with zip. >>> Just make sure odbc libraries are findable by Windows. >>> >>> Cheers >>> >>> On Sun, Dec 11, 2011 at 6:45 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> Fadi Mansour wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm having the same issue while trying to use ODBC with Pharo's OnClick >>>>> image 1.3. >>>>> >>>>> Did you find anything about the issue here? >>>>> >>>>> Regards, >>>>> >>>>> Fadi >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> I've been offline while attending to a machine rebuild shutdown on a >>>> mine site. I've only just got back today to start having a look at it >>>> again. >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 15, 2011

Re: [Pharo-project] FFI is broken in Cog - success^2 [WAS] Re: Pharo 1.3 vs 1.2.1 some results for ConfigurationOfODBC - success

by Ben Coman

Dec. 15, 2011

[Pharo-project] Technical "Debt" of Smalltalk with Moose? (was Re: An Improvement Over its Successors)

by Janko MivÅ¡ek

Hi guys, I'm wondering if we can produce the same comparison of Technical Debt with Moose technology comparing Smalltalk with Java, .NET and others, as in study below? >From study: Technical debt is highest in Java-EE, .NET second. Technical Debt represents the effort required to fix problems that remain in the code when an application is released. It is shown as cost per LOC. This year is by their study 3.61 USD in average. S, Janko MivÅ¡ek piÅ¡e: > S, Casey Ransberger piÅ¡e: > >> I read recently that a study done on enterprise apps written in many different languages found the most defects per capita in Java apps. This didn't come as a surprise, but what did: the apps with the lowest defect rates were written in COBOL. > > This study can be found here (registration needed): > > The CRASH Report - 2011/12 > (CAST Report on Application Software Health) > http://www.castsoftware.com/resources/resource/whitepapers/cast-report-on-a… > > Interesting read, recommended, findings can help improve our software too! > > >> The researchers seemed to scratch their heads and proclaim "...well, I guess there've been people grinding bugs off of the COBOL code for thirty years." >> >> After the horror stories that I read about on comp.lang.cobol (I have strange hobbies? Also, some of those COBOL guys have a lot to teach) I think I nearly fell out of my chair laughing and achieved something approaching enlightenment;) >> > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2011

Re: [Pharo-project] 1.3, PBE and lab setups

by Oscar Nierstrasz

Sure, that would be great, but please be aware that you must also check that the examples (and tests) work as advertised. If someone wants to do this please contact me, and I can give some advice and help ... on On 15 Dec 2011, at 08:48, stephane ducasse wrote: > > On Dec 15, 2011, at 2:24 AM, Serge Stinckwich wrote: > >> 2011/12/15 Dave Mason <dmason(a)mason-rose.ca>: >>> I am trying to get our local admins to set up labs so students can use the >>> latest Pharo. >>> >>> Currently we have 1.2 and PBE .image files and by removing the field in the >>> INI file that specified the image, if you clicked on Pharo, you'd get a >>> dialogue asking which image you wanted. All of these are on read-only >>> mounts, so if you want to save to the image, you need to copy the image to >>> your home directory and then you could navigate to that image file on >>> startup. Dropping an image on the executable works fine, though. >>> >>> Additionally, the PBE book doesn't play well with 1.3 (things that the book >>> says die when you try them). Apparently you can't open the PBE image from >>> the 1.3 binary without it crashing, either. >>> >>> So I have 3 questions: >>> >>> 1) is 1.3 the system to use, or will 1.4 be stable soon? >>> >>> 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? >> >> There is no plan at the moment to do that, but you could help adapt >> the Pharo Book to the new images. >> All the contents of the book is here: >> https://github.com/SquareBracketAssociates/PharoByExample-english >> >> Maybe we can have branches for each version of Pharo ? pharo1.2, >> pharo1.3, etc â¦ > > yes this would be really good to have a branch > > Stef > >> >> Regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Matsuno Laboratory, Kyoto University, Japan (until 12/2011) >> http://www.mechatronics.me.kyoto-u.ac.jp/ >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> Sbe-discussion mailing list >> Sbe-discussion(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >>

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Henrik Sperre Johansen

On 14.12.2011 02:10, Igor Stasenko wrote: > On 14 December 2011 01:17, Fernando Olivero<fernando.olivero(a)usi.ch> wrote: >> Igor, is this a bug? >> >> When parsing methods that send native functions withouth arguments , >> void, theres a DNU. >> For example in the following method: >> >> ^ self pangoCairoNbCall:#(PangoCairoFontMap >> pango_cairo_font_map_get_default ( void ) ) >> >> >> I fixed it like this: >> >> usesMethodArguments >> "first check wether my single argument is void" >> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >> usesSTStack ] ] >> >> > Well, the function signature syntax are not strictly following C. > Just use empty parens for functions with no arguments. This is quite > archaic C syntax, which is really not important to support. > > Or i can add this patch if you insist. :) So you would say f.ex. http://david.tribble.com/text/cdiffs.htm#C99-empty-parm is incorrect? Cheers, Henry

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by StÃ©phane Ducasse

Igor please make NB syntax robust to C silliness. Stef On Dec 15, 2011, at 2:08 AM, Fernando Olivero wrote: > Your right, this isnt a bug, NativeBoost is very well tested and works > really nice! > > I should reformulate the comment: 'if i new user of Native Boost, and > i copy and paste some Library method, to create a NB method in > smalltalk, and if it happens that that particular method is written > foo(void), then will i be able to know the origin of the DNU ?, that i > should just put foo() ?" > > For me it took a while of debugging before i understood the issue, > maybe others less eager to debug will think its a bug? Surely with a > good documentation and examples, it shouldn't be a problem. > > Fernando > > > On Thu, Dec 15, 2011 at 1:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 15 December 2011 00:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> I've insist. >>> >>> Because maybe somebody else runs into this bug, and thinks that NB is >>> broken, instead of understanding they should use new C syntax. For >>> examples i was using the latest Pango code. >> >> but this is NOT a bug. maybe a missing feature but not a bug. >> Is it so hard to put empty braces instead of void? :) And besides >> empty braces it is valid C syntax. >> >>> >>> If you want we could raise a warning, suggesting changing the code? >>> (maybe too disturbing). >>> >> no, i just dont understand why complicating a code for nothing? >> You can define a callout to functions with no arguments. >> If you would not be able to do so, then this can be considered a bug. >> >>> Fernando >>> >>> On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>>>> Igor, is this a bug? >>>>> >>>>> When parsing methods that send native functions withouth arguments , >>>>> void, theres a DNU. >>>>> For example in the following method: >>>>> >>>>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >>>>> pango_cairo_font_map_get_default ( void ) ) >>>>> >>>>> >>>>> I fixed it like this: >>>>> >>>>> usesMethodArguments >>>>> "first check wether my single argument is void" >>>>> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >>>>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >>>>> usesSTStack ] ] >>>>> >>>>> >>>> >>>> Well, the function signature syntax are not strictly following C. >>>> Just use empty parens for functions with no arguments. This is quite >>>> archaic C syntax, which is really not important to support. >>>> >>>> Or i can add this patch if you insist. :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >

Dec. 15, 2011

Re: [Pharo-project] [sbe-discussion] 1.3, PBE and lab setups

by stephane ducasse

On Dec 15, 2011, at 2:24 AM, Serge Stinckwich wrote: > 2011/12/15 Dave Mason <dmason(a)mason-rose.ca>: >> I am trying to get our local admins to set up labs so students can use the >> latest Pharo. >> >> Currently we have 1.2 and PBE .image files and by removing the field in the >> INI file that specified the image, if you clicked on Pharo, you'd get a >> dialogue asking which image you wanted. All of these are on read-only >> mounts, so if you want to save to the image, you need to copy the image to >> your home directory and then you could navigate to that image file on >> startup. Dropping an image on the executable works fine, though. >> >> Additionally, the PBE book doesn't play well with 1.3 (things that the book >> says die when you try them). Apparently you can't open the PBE image from >> the 1.3 binary without it crashing, either. >> >> So I have 3 questions: >> >> 1) is 1.3 the system to use, or will 1.4 be stable soon? >> >> 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? > > There is no plan at the moment to do that, but you could help adapt > the Pharo Book to the new images. > All the contents of the book is here: > https://github.com/SquareBracketAssociates/PharoByExample-english > > Maybe we can have branches for each version of Pharo ? pharo1.2, > pharo1.3, etc â¦ yes this would be really good to have a branch Stef > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Sbe-discussion mailing list > Sbe-discussion(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion >

Dec. 15, 2011

[Pharo-project] Class rename on materialization

by Martin Dias

Hi. We have recently discussed in a couple of threads about serialization & class renames. I want to ask you for the following case, because I'm not sure what should be the expected result. Suppose we serialize: Array with: OldClass new with: OldClass with: #OldClass. Then, we specify to the materializer that OldClass has been renamed to NewClass. Now, should we expect that result first -------> a NewClass second --> NewClass third ------> #NewClass or... result third ------> #OldClass ? In other words, should a class rename affect to every symbol in the graph? Thanks, MartÃn

Dec. 15, 2011

[Pharo-project] Magma in production ?

by Francois Stephany

Is there anybody using the Magma OODB in production? For what kind of application? How does it behave under load? How large is your dataset? How do you perform external backup? What's the best setup? One dedicated image? Cheers, Francois -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Dec. 15, 2011

Re: [Pharo-project] NB Bug?

by Schwab,Wilhelm K

I see this as a missing feature for one reason: as silly as the syntax might be, it is used in the wild. Until gcc rejects it, it would be nice if NB would accept it. The closer we get toward what should be our ultimate goal (header files in, working binding out), the more details like these matter. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Fernando Olivero [fernando.olivero(a)usi.ch] Sent: Wednesday, December 14, 2011 8:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NB Bug? Your right, this isnt a bug, NativeBoost is very well tested and works really nice! I should reformulate the comment: 'if i new user of Native Boost, and i copy and paste some Library method, to create a NB method in smalltalk, and if it happens that that particular method is written foo(void), then will i be able to know the origin of the DNU ?, that i should just put foo() ?" For me it took a while of debugging before i understood the issue, maybe others less eager to debug will think its a bug? Surely with a good documentation and examples, it shouldn't be a problem. Fernando On Thu, Dec 15, 2011 at 1:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 15 December 2011 00:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I've insist. >> >> Because maybe somebody else runs into this bug, and thinks that NB is >> broken, instead of understanding they should use new C syntax. For >> examples i was using the latest Pango code. > > but this is NOT a bug. maybe a missing feature but not a bug. > Is it so hard to put empty braces instead of void? :) And besides > empty braces it is valid C syntax. > >> >> If you want we could raise a warning, suggesting changing the code? >> (maybe too disturbing). >> > no, i just dont understand why complicating a code for nothing? > You can define a callout to functions with no arguments. > If you would not be able to do so, then this can be considered a bug. > >> Fernando >> >> On Wed, Dec 14, 2011 at 2:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 14 December 2011 01:17, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>>> Igor, is this a bug? >>>> >>>> When parsing methods that send native functions withouth arguments , >>>> void, theres a DNU. >>>> For example in the following method: >>>> >>>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >>>> pango_cairo_font_map_get_default ( void ) ) >>>> >>>> >>>> I fixed it like this: >>>> >>>> usesMethodArguments >>>> "first check wether my single argument is void" >>>> ^(fnSpec arguments size = 1 ==> [fnSpec arguments first class ~= >>>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >>>> usesSTStack ] ] >>>> >>>> >>> >>> Well, the function signature syntax are not strictly following C. >>> Just use empty parens for functions with no arguments. This is quite >>> archaic C syntax, which is really not important to support. >>> >>> Or i can add this patch if you insist. :) >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko.

Dec. 15, 2011