July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] th/m/ ''' e return of the strange methods

by Jeff Estep

'' On Jul 9, 2013 11:43 AM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote:////,,. > > They may be useful. Imagine you are too lazy to create /a subclass of Error, but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString >> > >> > I honestly cannot wrap my ojhjuj around these two methods. >>c >> ''' show that the code in the block raises an ,,''',. >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> > Cf'

July 10, 2013

Re: [Pharo-dev] UIPainter in need of some help?

by Stephan Eggermont

Erwan wrote: >Do you know how i can replace the background of a SpecWindow ? >I would like to use UIPainterPanelMorph, which provide me drag'n drop. I would assume you can set the bindings of the SpecInterpreter to a SpecBinder with a different initializeBindings? That suggest that SpecBindings should perhaps not be a singleton Stephan

July 10, 2013

Re: [Pharo-dev] filetree jenkins job

by Christophe Demarey

Hi Dale, The introduction of Opal as the new compiler has some side effects. The problem is reported here : https://pharo.fogbugz.com/default.asp?11141 Today, Camillo and I worked on this problem and we should come with a solution soon. Once integrated in the image, you should have the same kind of output you have on Pharo 2.0. Maybe you can trigger a new build for Pharo 3.0. There was also a bug related the new classBuilder introduction and it is now fixed. Le 8 juil. 2013 Ã 05:04, Dale K. Henrichs a Ã©crit : > When I am using travis, I am looking at the log file of the run just to see if the test passed or failed, so to have a "dead stack trace" right there in the log file that I am looking at is exactly what I WANT ... most of the time the stack trace is enough for me to debug the problem... > > | And exactly in the case you describe theses fuel files can save you a > | lot of time since you can basically debug the same way you debug a > | local application. > > Except that I rarely write code in Pharo3.0, but I am interested in running tests and seeing the results of tests and seeing stack traces for failures for the code when it is run against Pharo3.0 ... These days I do the bulk of my development for FileTree, Metacello, etc. using tODE in GemStone, so I don't usually even have a Pharo development image (especially a fresh one) available to do testing ... so a stack trace actually saves me a whole lot of time... Here Camillo just pointed you a very useful mechanism you can use to debug. At the end, you are free to check stack traces and try to fix from tODE/GemStone if you prefer this way. > | In any case I see 4 failing tests on our jenkins build: > | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable… If you don't want to wait to have feedback from Travis with the error output fixed, this is the way to go. You can get the stack trace by clicking on each failed test. We should have the same failed tests on Travis. Christophe.

July 10, 2013

Re: [Pharo-dev] [Pharo-bugtracker] FogBugz (Case [Issue]11132) Tools - Backport to 2.0: Convert MetacelloConfigurationBrowser to Spec

by Sven Van Caekenberghe

On 10 Jul 2013, at 17:18, "Pharo Issue Tracker" <do-not-reply(a)pharo.fogbugz.com> wrote: > The new config browser: > > 1. Avoids the confusion of newbees (remember the "why is this tab named > Verified vs. Unverified" discussion). It now displays ONLY the > verified configs that are specific to Pharo 2.0 (from MetaRepoForPharo20) > but still allows you to switch repository so you load and browse > others > > 2. Switched the repo URL to "gemtalksystems" instead of "gemstone" > since SS3 moved to the new company > > 3. has a nicer look and feel with icons > > 4. Shows when a config is already loaded > > 5. is cleaner since it is based on spec Thx, Torsten, the new browser is cool, I like it. Sven

July 10, 2013

Re: [Pharo-dev] [update 3.0] #30262

by Sven Van Caekenberghe

On 10 Jul 2013, at 11:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30262 > ----- > > 11089 Update Zn+Zdc July 2013 > https://pharo.fogbugz.com/f/cases/11089 > Thanks, Marcus. And the versions were kept the same ;-) To bad there remain strange differences between tests passing/failing on the build servers and locally. Sven

July 10, 2013

Re: [Pharo-dev] Is it Glorp trustful enough for the encoding?

by Esteban A. Maringolo

2013/7/10 Sven Van Caekenberghe <sven(a)stfx.eu>: >> So...where should I do the conversion? At Glorp level or at database driver level? > And IMHO at the lowest possible level. If you have an SQL VARCHAR column, the driver should convert bytes to a normal Smalltalk String. An OR mapper is a client of the driver, right ? +1 Encoding should be a parameter of the Connection/Login details. And ORM should deal only with strings in whatever encoding Pharo uses for its strings, ignoring (as much as possible) what happens beneath. Regards,

July 10, 2013

Re: [Pharo-dev] Some Spec questions

by ClÃ©ment Bera

2013/7/10 ClÃ©ment Bera <bera.clement(a)gmail.com> > Hello, > > So in the current spec debugger, the receiver's inspector widget is > changed dynamically. Even if it looks like the same because it is always an > inspector, it is not the same widget (could be any subclass of EyeInspector > depending on receiver's type). So it is possible to change the main > debugger spec dynamically object side. > > To change dynamically you have to do something like: > MyClass class>>myDynamicLayout > <spec> > ^ SpecLayout composed > add: #aModel; > yourself > MyClass>>changeLayoutDynamically > self buildWithSpec: #myDynamicLayout. > > Then you can add: > aComposableModel needRebuild: false > on some widgets not to rebuild them and to speed up the spec generation. > > However, as this was too slow to do it for the full debugger (in the case > of the receiver inspector), an inspectorWrapper class was made so the > debugger has fixed spec and only the inspector wrapper spec changed. > Depending on how often you change the toolbar, you may need to do something > similar, even if it's a bit overly complex. > Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this problem (I've just learnt that a few minutes ago). You may discuss with him about that. > > You can have a look at inspectorWrapper, in Pharo 3.0. > (InspectorWrapper>>updateInspectorFrom:) > > Hope it helped you, > > > > > 2013/7/10 Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > >> >> > Hi folks, while working on the new debugger, I've come up with some >>> questions... >>> > >>> > *is there any other implementation for dynamic widgets other that the >>> current one? >>> >>> I do not get your question ... >>> >> >> >> This is related to my previous question about dynamic spec, if it's >> possible to define the layout of >> a widget on the object side. >> >> >>> >>> > >>> > *right now the toolbar is a static widget, and I would like to have a >>> dynamic one to filter out the actions that should not be available (which >>> are a subset of the default ones). Would it make sense to regenerate the >>> toolbar everytime the selection changes? Is there any other approach I >>> should consider? >>> >>> It may make sense to dynamically regenerate the toolbar (or at least >>> remove only what needs to be removed, add only what needs to be added). >>> Then you should also think in term of user experience. Having things >>> changing may be disturbing and counter productive :) >> >> >> Right now our use case are post mortem contexts (that do not have a >> process attached). In there case only few actions make sense. >> The current debugger sets the toolbar at the creation of the debugger. If >> the context turns post mortem during debugging the actions should also >> change. Now the question would be if this is actually possible? >> >> >> > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

July 10, 2013

Re: [Pharo-dev] Is it Glorp trustful enough for the encoding?

by Sven Van Caekenberghe

On 10 Jul 2013, at 17:00, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. It may happen that both, Glorp and the database driver in question, support an encoding strategy. In Pharo, both drivers (NativePostgresDriver and OpenDBXDriver) does support setting an encoding and take care of it. But Glorp supports that as well. > I want to avoid doing double conversion... > > So...where should I do the conversion? At Glorp level or at database driver level? > Is glorp trustful enough for the encoding? UserGuide says nothing about it. It should certainly only happen once ! And IMHO at the lowest possible level. If you have an SQL VARCHAR column, the driver should convert bytes to a normal Smalltalk String. An OR mapper is a client of the driver, right ? > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com

July 10, 2013

Is it Glorp trustful enough for the encoding?

by Mariano Martinez Peck

Hi guys. It may happen that both, Glorp and the database driver in question, support an encoding strategy. In Pharo, both drivers (NativePostgresDriver and OpenDBXDriver) does support setting an encoding and take care of it. But Glorp supports that as well. I want to avoid doing double conversion... So...where should I do the conversion? At Glorp level or at database driver level? Is glorp trustful enough for the encoding? UserGuide says nothing about it. Thanks, -- Mariano http://marianopeck.wordpress.com

July 10, 2013

Re: [Pharo-dev] Best way to covert a ByteArray to a string with a particular encoding?

by Sven Van Caekenberghe

On 10 Jul 2013, at 16:44, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. There is a method in Glorp that looks like this: > > Dialect >> #convert: aByteArray toStringWithEncoding: encodingName > self isVisualWorks ifTrue: [^aByteArray asStringEncoding: encodingName]. > self error: 'Not yet implemented'. > > So I wanted to implement it in Pharo. I thought about: > > self isPharo ifTrue: [ ^aByteArray asString convertToEncoding: encodingName ]. > > but I am not sure. > > Opinions? That is using the existing TextConverter framework. An alternative is to use ZnCharacterEncoder. (ZnCharacterEncoder newForEncoding: encodingName) decodeBytes: aByteArray. (ZnCharacterEncoder newForEncoding: encodingName) encodeString: aString. Sven > -- > Mariano > http://marianopeck.wordpress.com

July 10, 2013