July 2015 - Pharo-users - lists.pharo.org

Pillar and Beamer

by Peter UhnÃ¡k

Hi, there was a presentation (or show us your project) about Pillar and (LaTeX/)Beamer at ESUG if I am not mistaken. However I don't think there are videos available from the uni, so is more information available somewhere? Thanks, Peter

July 29, 2015

Re: [Pharo-users] Is RBClassNotReferencedRule ~200x slower in Pharo 4 vs Pharo 3 ?

by stepharo

Paul I wanted to check on Pharo 50 but we need a comparison point. We should get the same package. Do you have an idea of a package that did not change much? Setf Le 29/7/15 06:04, Paul DeBruicker a Ã©crit : > I think I'm setting this up wrong in Pharo 4 but am not sure. I use the following code for the test: > > > rule:=RBClassNotReferencedRule new. > environment:=RBBrowserEnvironment new forPackageNames: #('MyPackage'). > > > AndreasSystemProfiler spyOn:[RBSmalllintChecker runRule: rule onEnvironment: environment] > > > In Pharo 4 it spends most of the time in Behavior>>#includesDefinedSelector:ofClassName: and takes 300s. In Pharo 3 its only 1.5 s > > Is there something that can be done to get Pharo 4 up to the speed of Pharo 3? > > > Thanks > > Paul >

July 29, 2015

Re: [Pharo-users] Is RBClassNotReferencedRule ~200x slower in Pharo 4 vs Pharo 3 ?

by stepharo

Thanks for the question. It looks like we got a regression. Le 29/7/15 06:04, Paul DeBruicker a Ã©crit : > I think I'm setting this up wrong in Pharo 4 but am not sure. I use the following code for the test: > > > rule:=RBClassNotReferencedRule new. > environment:=RBBrowserEnvironment new forPackageNames: #('MyPackage'). > > > AndreasSystemProfiler spyOn:[RBSmalllintChecker runRule: rule onEnvironment: environment] > > > In Pharo 4 it spends most of the time in Behavior>>#includesDefinedSelector:ofClassName: and takes 300s. In Pharo 3 its only 1.5 s > > Is there something that can be done to get Pharo 4 up to the speed of Pharo 3? > > > Thanks > > Paul >

July 29, 2015

Is RBClassNotReferencedRule ~200x slower in Pharo 4 vs Pharo 3 ?

by Paul DeBruicker

I think I'm setting this up wrong in Pharo 4 but am not sure. I use the following code for the test: rule:=RBClassNotReferencedRule new. environment:=RBBrowserEnvironment new forPackageNames: #('MyPackage'). AndreasSystemProfiler spyOn:[RBSmalllintChecker runRule: rule onEnvironment: environment] In Pharo 4 it spends most of the time in Behavior>>#includesDefinedSelector:ofClassName: and takes 300s. In Pharo 3 its only 1.5 s Is there something that can be done to get Pharo 4 up to the speed of Pharo 3? Thanks Paul

July 29, 2015

Re: [Pharo-users] New methods for the String class

by Cameron Sanders

Thank You! -cam On Tue, Jul 28, 2015 at 11:39 AM, Cameron Sanders via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Cameron Sanders <camsanders(a)aol.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Date: Tue, 28 Jul 2015 11:00:11 -0400 > Subject: Re: [Pharo-users] New methods for the String class > What fuzzy-string matching tools & packages are available today? > > -cam > > On Wed, Feb 26, 2014 at 9:09 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> >> >> >> 2014-02-26 7:10 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> >>> Am 26.02.2014 um 09:50 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: >>> >>> >>> We can have an information retrieval API for aproximate string matching, >>> i.e. Levenshtein distance (already implemented, various versions), Hamming >>> distance, both are the most used and simplest edit distances. >>> Then you have Longest common subsequence, Longest common substring (they >>> are implemented in a package called "Fuzz", #longestCommonSubsequenceWith: >>> ). Also there is the shift-or adapted for approximate matches (also >>> implemented), fuzzy phrasing is another world also. Many applications use >>> Damerau edit distance. Bioinformatics uses the Needleman-Wunsch and >>> Smith-Waterman, but they call them "aligners" :) but you don't want to code >>> the optimized version in Smalltalk, some say it could take years. >>> All edit distances out there have specific requirements and no one is >>> better than another for all cases. For example Jaro-Winkler is useful for >>> one-word short strings. >>> >>> >>> Iâm not sure that all these edit distances should be part of the String >>> core api. >>> Now what would be good is to have a chapter describing them. This >>> chapter would work well with the bioSmalltalk one :) >>> >>> Iâm pretty sure they shouldnât. Most of these are most likely for >>> special applications. So a perfect candidate for a string extension >>> package. A real modular entity that could load each of them individually >>> would be perfect but we donât have the proper tools, yet. Unless of course >>> every of those algorithms is composed of multiple classes and would fit >>> naturally in a package. >>> >> >> Absolutely for a separate package for information retrieval algorithms. >> From what I've seen, some algorithms require optimization through dynamic >> programming (automatas, matrices, etc) and that would lead to multiple >> classes, assuming you don't want to get dirty String class. >> >> >>> But the most important prerequisite would be to make a separate package >>> out of it. Did I understand that right that those are part of biosmalltalk? >>> >> >> No. Those algorithms are spread over different packages in repositories >> like SqueakSource, Cincom Store, etc. >> >> HernÃ¡n >> >> >> > >

July 29, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Yuriy Tymchuk

Alex, Ronie, do you have any idea what can cause the issue? Because Iâve never worked with native boost. Uko > On 28 Jul 2015, at 20:52, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > Hi Yuriy, > > I've tried with the latest changes but the problem described in my previous email still persists: > > "Error: Could not find accessor for variable named "aModuleName" in NativeBoost>>#loadModule:" > > All your recommendations will be very welcomed. > > Thank you. > > Rafa > > > > 2015-04-24 18:13 GMT+02:00 Rafael Luque <rafael.luque.leiva(a)gmail.com <mailto:rafael.luque.leiva@gmail.com>>: > Hi Uko > > I've just tried with your last changes, but I get the same error: "Error: Could not find accessor for variable named "aModuleName" in NativeBoost>>#loadModule:" > > This is the stack trace for your information: > > =========================================== > > NBFFICallout>>loaderForArgNamed: > NBFFICallout>>loaderForArgNamed:indirectIndex: > NBFFICallout>>argName:indirectIndex:type:ptrArity: > NBFnSpecParser>>parseArgument > NBFnSpecParser>>parseArguments > NBFnSpecParser>>parseAnonFunction: > NBFFICallout>>anonSpec: > [ :t3 | > t3 > useEmitCall; > callType: conv; > sender: context; > parseOptions: options; > anonSpec: t1; > generate: t2 ] in NBFFICalloutAPI>>function:emit: > [ t6 := t1 value: (self newForMethod: t3) ] in NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: > BlockClosure>>on:do: > NBRecursionDetect class>>in:during: > NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: > NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > NBFFICalloutAPI>>function:emit: > NativeBoostMac32(NativeBoost)>>loadModule: > CairoLibraryLoader class>>loadCairoLibrary > CairoLibraryLoader class>>getLibraryHandle > AthensCairoSurface class>>nbLibraryNameOrHandle > AthensCairoSurface class(Object)>>nbCall: > AthensCairoSurface class>>primImage:width:height: > AthensCairoSurface class>>extent:format: > AthensCairoSurface class>>extent: > TRCanvas>>initialize > TRCanvas class(Behavior)>>new > RTView>>initialize > RTView class(Behavior)>>new > R3View>>initialize > R3View class(Behavior)>>new > Roassal3DModel>>initialize > Roassal3DModel class(Behavior)>>new > Roassal3DModel class(ComposableModel class)>>owner: > CityBrowser(ComposableModel)>>instantiate: > CityBrowser>>initializeWidgets > CityBrowser(ComposableModel)>>initialize > CityBrowser class(Behavior)>>new > CityBrowser class(ComposableModel class)>>owner: > VidiBrowser(ComposableModel)>>instantiate: > VidiBrowser>>initializeWidgets > VidiBrowser(ComposableModel)>>initialize > VidiBrowser>>initialize > VidiBrowser class(Behavior)>>new > ReModel>>vidi > VidiSession>>openVidi > [ (VidiSessionManager default newSessionOnPackages: packages) openVidi ] in VidiSessionPackagesSelect>>nextAction > [ > self value. > Processor terminateActive ] in BlockClosure>>newProcess > > =========================================== > > > Thank you. > > 2015-04-24 14:25 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi Rafael, > > now ViDI should work. I havenât been working on it for a while, but feel free to report more issues, as Iâll get back to it soon. > > Uko > > > >> On 24 Apr 2015, at 09:57, Rafael Luque <rafael.luque.leiva(a)gmail.com <mailto:rafael.luque.leiva@gmail.com>> wrote: >> >> Thank you! I'm looking forward to hearing from you about the new version. >> >> 2015-04-24 9:52 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >> Ok, I found the problem. Some Spec api changed. I stable version will work at least on Mac quite soon. :) >> >> Uko >> >> >> >>> On 23 Apr 2015, at 17:46, Rafael Luque <rafael.luque.leiva(a)gmail.com <mailto:rafael.luque.leiva@gmail.com>> wrote: >>> >>> I'd like to use it in a Linux box, but as you told me Linux is not yet supported, I'm using a Mac OS X Yosemite (version 10.10.2). >>> >>> Thanks >>> >>> 2015-04-23 17:37 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>> Hi Rafael, >>> >>> I will take a look. Which operating system are you using? >>> >>> Uko >>> >>>> On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com <mailto:rafael.luque.leiva@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> I installed ViDI on Pharo 4 following the project instructions detailed in its GitHub page: >>>> >>>> Gofer new >>>> smalltalkhubUser: 'YuriyTymchuk' >>>> project: 'Configuration'; >>>> configurationOf: 'Vidi'; >>>> load. >>>> #ConfigurationOfVidi asClass loadStable >>>> >>>> When I launch a review session over any package I always get the following error: >>>> >>>> "Could not find accesor for variable named "aModuleName" in NativeBoost>>#loadModule:" >>>> >>>> I'm very interested in this kind of quality assurance tools, so any help will be very welcomed. >>>> >>>> Thank you. >>> >>> >> >> > > >

July 28, 2015

Re: [Pharo-users] troubles with JNIPort on Pharo 5 / Java 8

by Joachim Geidel

Hi Tudor, unfortunately I havenât had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isnât finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I canât tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now. Cheers, Joachim > Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <ml-node+s1294792n4839785h23(a)n4.nabble.com>: > > Hi Joachim, > > Thanks for the answer. > > I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it: > https://support.apple.com/kb/DL1572?locale=en_US <https://support.apple.com/kb/DL1572?locale=en_US> > > I still have problems in Pharo5. > > I am trying the following script: > http://ws.stfx.eu/CHS8KCAGWGO2 <http://ws.stfx.eu/CHS8KCAGWGO2> > > I tried in Pharo 3, and the script worked fine. > > I also tried with Pharo4 and Pharo5, but it does not work because I get a MNU for GhostClassBuilder>>#client:. > > I fixed it in a Pharo5 image by using #installer: instead, but the computation of "JVM newWithSettings: jvmSettings" does not seem to finish and it blocks the VM. > > Any idea of what goes wrong? > > Cheers, > Tudor -- View this message in context: http://forum.world.st/troubles-with-JNIPort-on-Pharo-5-Java-8-tp4836922p483… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 28, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Rafael Luque

Hi Yuriy, I've tried with the latest changes but the problem described in my previous email still persists: "Error: Could not find accessor for variable named "aModuleName" in NativeBoost>>#loadModule:" All your recommendations will be very welcomed. Thank you. Rafa 2015-04-24 18:13 GMT+02:00 Rafael Luque <rafael.luque.leiva(a)gmail.com>: > Hi Uko > > I've just tried with your last changes, but I get the same error: "Error: > Could not find accessor for variable named "aModuleName" in > NativeBoost>>#loadModule:" > > This is the stack trace for your information: > > =========================================== > > NBFFICallout>>loaderForArgNamed: > NBFFICallout>>loaderForArgNamed:indirectIndex: > NBFFICallout>>argName:indirectIndex:type:ptrArity: > NBFnSpecParser>>parseArgument > NBFnSpecParser>>parseArguments > NBFnSpecParser>>parseAnonFunction: > NBFFICallout>>anonSpec: > [ :t3 | > t3 > useEmitCall; > callType: conv; > sender: context; > parseOptions: options; > anonSpec: t1; > generate: t2 ] in NBFFICalloutAPI>>function:emit: > [ t6 := t1 value: (self newForMethod: t3) ] in NBFFICallout > class(NBNativeCodeGen class)>>generateCode:andRetry: > BlockClosure>>on:do: > NBRecursionDetect class>>in:during: > NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: > NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > NBFFICalloutAPI>>function:emit: > NativeBoostMac32(NativeBoost)>>loadModule: > CairoLibraryLoader class>>loadCairoLibrary > CairoLibraryLoader class>>getLibraryHandle > AthensCairoSurface class>>nbLibraryNameOrHandle > AthensCairoSurface class(Object)>>nbCall: > AthensCairoSurface class>>primImage:width:height: > AthensCairoSurface class>>extent:format: > AthensCairoSurface class>>extent: > TRCanvas>>initialize > TRCanvas class(Behavior)>>new > RTView>>initialize > RTView class(Behavior)>>new > R3View>>initialize > R3View class(Behavior)>>new > Roassal3DModel>>initialize > Roassal3DModel class(Behavior)>>new > Roassal3DModel class(ComposableModel class)>>owner: > CityBrowser(ComposableModel)>>instantiate: > CityBrowser>>initializeWidgets > CityBrowser(ComposableModel)>>initialize > CityBrowser class(Behavior)>>new > CityBrowser class(ComposableModel class)>>owner: > VidiBrowser(ComposableModel)>>instantiate: > VidiBrowser>>initializeWidgets > VidiBrowser(ComposableModel)>>initialize > VidiBrowser>>initialize > VidiBrowser class(Behavior)>>new > ReModel>>vidi > VidiSession>>openVidi > [ (VidiSessionManager default newSessionOnPackages: packages) openVidi ] > in VidiSessionPackagesSelect>>nextAction > [ > self value. > Processor terminateActive ] in BlockClosure>>newProcess > > =========================================== > > > Thank you. > > 2015-04-24 14:25 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi Rafael, >> >> now ViDI should work. I havenât been working on it for a while, but feel >> free to report more issues, as Iâll get back to it soon. >> >> Uko >> >> >> >> On 24 Apr 2015, at 09:57, Rafael Luque <rafael.luque.leiva(a)gmail.com> >> wrote: >> >> Thank you! I'm looking forward to hearing from you about the new version. >> >> 2015-04-24 9:52 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >>> Ok, I found the problem. Some Spec api changed. I stable version will >>> work at least on Mac quite soon. :) >>> >>> Uko >>> >>> >>> >>> On 23 Apr 2015, at 17:46, Rafael Luque <rafael.luque.leiva(a)gmail.com> >>> wrote: >>> >>> I'd like to use it in a Linux box, but as you told me Linux is not yet >>> supported, I'm using a Mac OS X Yosemite (version 10.10.2). >>> >>> Thanks >>> >>> 2015-04-23 17:37 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >>> >>>> Hi Rafael, >>>> >>>> I will take a look. Which operating system are you using? >>>> >>>> Uko >>>> >>>> On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I installed ViDI on Pharo 4 following the project instructions >>>> detailed in its GitHub page: >>>> >>>> Gofer new >>>> smalltalkhubUser: 'YuriyTymchuk' >>>> project: 'Configuration'; >>>> configurationOf: 'Vidi'; >>>> load. >>>> #ConfigurationOfVidi asClass loadStable >>>> >>>> When I launch a review session over any package I always get the >>>> following error: >>>> >>>> "Could not find accesor for variable named "aModuleName" in >>>> NativeBoost>>#loadModule:" >>>> >>>> I'm very interested in this kind of quality assurance tools, so any >>>> help will be very welcomed. >>>> >>>> Thank you. >>>> >>>> >>>> >>> >>> >> >> >

July 28, 2015

Re: [Pharo-users] New methods for the String class

by stepharo

Hi I know that Olivier Auverlot has all kind of string distance. Hernan Morales has also a package extending string. Stef

July 28, 2015

Re: [Pharo-users] New methods for the String class

by Cameron Sanders

What fuzzy-string matching tools & packages are available today? -cam On Wed, Feb 26, 2014 at 9:09 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > > > 2014-02-26 7:10 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > >> >> Am 26.02.2014 um 09:50 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: >> >> >> We can have an information retrieval API for aproximate string matching, >> i.e. Levenshtein distance (already implemented, various versions), Hamming >> distance, both are the most used and simplest edit distances. >> Then you have Longest common subsequence, Longest common substring (they >> are implemented in a package called "Fuzz", #longestCommonSubsequenceWith: >> ). Also there is the shift-or adapted for approximate matches (also >> implemented), fuzzy phrasing is another world also. Many applications use >> Damerau edit distance. Bioinformatics uses the Needleman-Wunsch and >> Smith-Waterman, but they call them "aligners" :) but you don't want to code >> the optimized version in Smalltalk, some say it could take years. >> All edit distances out there have specific requirements and no one is >> better than another for all cases. For example Jaro-Winkler is useful for >> one-word short strings. >> >> >> Iâm not sure that all these edit distances should be part of the String >> core api. >> Now what would be good is to have a chapter describing them. This chapter >> would work well with the bioSmalltalk one :) >> >> Iâm pretty sure they shouldnât. Most of these are most likely for special >> applications. So a perfect candidate for a string extension package. A real >> modular entity that could load each of them individually would be perfect >> but we donât have the proper tools, yet. Unless of course every of those >> algorithms is composed of multiple classes and would fit naturally in a >> package. >> > > Absolutely for a separate package for information retrieval algorithms. > From what I've seen, some algorithms require optimization through dynamic > programming (automatas, matrices, etc) and that would lead to multiple > classes, assuming you don't want to get dirty String class. > > >> But the most important prerequisite would be to make a separate package >> out of it. Did I understand that right that those are part of biosmalltalk? >> > > No. Those algorithms are spread over different packages in repositories > like SqueakSource, Cincom Store, etc. > > HernÃ¡n > > >

July 28, 2015