- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Hijri calendar

by Paul DeBruicker

Torsten Bergmann wrote > Paul DeBruicker wrote >> Chronos has: >> ... >> Is that what you want? > > The www.chronos-st.org seems to be gone. But there is > http://smalltalkhub.com/#!/~Chronos/Chronos/ > > Thanks - I will have a look. Is it known to work in Pharo 3.0? > > Thx > T. Eh it will probably die because the base config loads code that uses FileDirectory. I did port it to Pharo 2. I think if you edit the ConfigurationOfChronos to load into Pharo 3 what it loads into Pharo 2 it should work OK. But I haven't tried it. -- View this message in context: http://forum.world.st/Hijri-calendar-tp4756080p4756106.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2014

Re: [Pharo-dev] Lost in spec

by Igor Stasenko

On 22 April 2014 21:02, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-04-22 13:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > i want to use different adaptor for TextModel, when opening my UI >> so that when widget is built for it, it will be my own widget, >> not PluggableTextMorph.. >> >> but i found it hard to do.. here what i tried: >> >> >> I try to replace bindings, so at the stage when spec interpreted, it uses >> my bindings: >> >> openWithSpec >> >> | old result | >> old := SpecInterpreter bindings. >> >> SpecInterpreter bindings: TxAdapterBindings new. >> >> [ result := super openWithSpec ] >> ensure: [ SpecInterpreter bindings: old ]. >> ^ result >> >> >> in TxAdapterBindings i initialize it same as morphic bindging, except >> from text model binding: >> #TextAdapter => #TxTextAdapter >> >> but it is never invoked nor used :( >> >> i understand the overall model, but it seems like not completely, >> (else the above trick would work).. what do i miss? >> >> -- >> Best regards, >> Igor Stasenko. >> > > > You code works, it is just that the TextModel is not the first one that > calls the > spec interpreter. The first one is the WindowModel. > And after a spec is "interpreted" spec interpreter calls > self hardResetBindings > and that one reinitialize the binding to MorphicAdapterBindings. > > indeed.. now i wonder, why spec interpreter is doing such nasty things? because because of it, you lose any control over bindings , when building composite UI. if spec interpreter exposing bindings to outside, it must never reset them, because it should be a user's concern, when/where reset or replace them. otherwise it makes little sense in having bindings, if spec interpreter forces to always use default ones. > nicolai > -- Best regards, Igor Stasenko.

April 23, 2014

Re: [Pharo-dev] Hijri calendar

by Torsten Bergmann

Paul DeBruicker wrote > Chronos has: > ... > Is that what you want? The www.chronos-st.org seems to be gone. But there is http://smalltalkhub.com/#!/~Chronos/Chronos/ Thanks - I will have a look. Is it known to work in Pharo 3.0? Thx T.

April 23, 2014

Re: [Pharo-dev] GUI TestRunner failures not found by CI (was Re: [pharo-project/pharo-core] 1953a9: 30829)

by Sven Van Caekenberghe

On 23 Apr 2014, at 19:55, Ben Coman <btc(a)openInWorld.com> wrote: > Sven Van Caekenberghe wrote: >> And we're all GREEN, great work ! >> Let's keep it that way until release. >> Everything that breaks a test should now be reverted. >> >> > Thats great news. However while the CI monkey is great, there are still a few tests (at least in Windows) that fail in a fresh image since: > * they are bypassed by the CI > * they are not run on a Windows CI slave > > I fixed a few similar failures but ran out of time to finish this. It might be worthwhile some others doing a pass the old fashioned way via the TestRunner GUI. Thats what users will end up seeing. It would be "real nice" if TestRunner showed users ALL GREEN for the Released image. I've just started a run with the latest image while I head off to bed. I'll report more on the issue tracker tomorrow. Agreed, but we know from experience that running the tests in a very controlled environment is the only way to have a common frame of reference. Yes, there are always a couple of guys that will download the release, run all tests and complain about a couple of failures. It would be super if we could avoid that, but I am pretty sure that will not happen (i.e. they will not succeed 100% for everyone). More eyes (especially on, the many different variants of, Windows) will always help, but the community is what it is. Sven

April 23, 2014

Re: [Pharo-dev] Hijri calendar

by Paul DeBruicker

Chronos has: "IslamicFatimidCalendar Concept: IslamicFatimidCalendar implements the Islamic Fatimid Calendar. The Islamic Fatimid Calendar (also called the Tabular Islamic Calendar) is an arithmetical variation of the Astronomical Islamic Calendar (the one most Muslims use for religious purposes.) It has the same year numbers and months, but the months are determined by arithmetic rules rather than by observation or astronomical calculations. It was developed by early Muslim astronomers of the second Hijra century (the eighth century AD) to provide a predictable time base for calculating the positions of the moon, sun, and planets. Historians use it to convert an Islamic date into a Western calendar date when no other information (like the day of the week) is available. Some Muslims (e.g, the Daudi Bohras, the Isma'ilis) also use the arithmetical calendar for regligous purposes [reference: http://archive.mumineen.org/publications/oup/bohras.html] All Muslims commonly use it to estimate future (and sometimes past) dates." Is that what you want? Torsten Bergmann wrote > Do we have support/code for that somewhere? > > Thx > T. -- View this message in context: http://forum.world.st/Hijri-calendar-tp4756080p4756085.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2014

GUI TestRunner failures not found by CI (was Re: [pharo-project/pharo-core] 1953a9: 30829)

by Ben Coman

Sven Van Caekenberghe wrote: > And we're all GREEN, great work ! > Let's keep it that way until release. > Everything that breaks a test should now be reverted. > > > Thats great news. However while the CI monkey is great, there are still a few tests (at least in Windows) that fail in a fresh image since: * they are bypassed by the CI * they are not run on a Windows CI slave I fixed a few similar failures but ran out of time to finish this. It might be worthwhile some others doing a pass the old fashioned way via the TestRunner GUI. Thats what users will end up seeing. It would be "real nice" if TestRunner showed users ALL GREEN for the Released image. I've just started a run with the latest image while I head off to bed. I'll report more on the issue tracker tomorrow. cheer -ben

April 23, 2014

Hijri calendar

by Torsten Bergmann

Do we have support/code for that somewhere? Thx T.

April 23, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829

by Marcus Denker

On 23 Apr 2014, at 19:21, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 23 avr. 2014, at 19:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 23 Apr 2014, at 18:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 23 Apr 2014, at 18:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> And we're all GREEN, great work ! >>>> Let's keep it that way until release. >>>> Everything that breaks a test should now be reverted. >>>> >>> Yes! >>> >>> there are just two issues that are for pharo3 with fixes: >>> >>> https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… >>> >> >> Ok, so loading that one brakes *everything*. >> >> (the build did not get done, so no problem, other than a red build) >> >> I will revert tomorrow... > > Arg, I'm sick of that issue. > So do we try to integrate it in two passes? > I have no idea what goes wrongâ¦ it seems that it works fine when I merge the slice. But then the update process (which just saved the packagesâ¦) does something wrong. Mayeb we could try to have a version without the method that sends #explicitRequirement Marcus

April 23, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829

by Camille Teruel

On 23 avr. 2014, at 19:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 23 Apr 2014, at 18:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 23 Apr 2014, at 18:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> And we're all GREEN, great work ! >>> Let's keep it that way until release. >>> Everything that breaks a test should now be reverted. >>> >> Yes! >> >> there are just two issues that are for pharo3 with fixes: >> >> https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… >> > > Ok, so loading that one brakes *everything*. > > (the build did not get done, so no problem, other than a red build) > > I will revert tomorrow... Arg, I'm sick of that issue. So do we try to integrate it in two passes? > > Marcus

April 23, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829

by Marcus Denker

On 23 Apr 2014, at 18:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 23 Apr 2014, at 18:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> And we're all GREEN, great work ! >> Let's keep it that way until release. >> Everything that breaks a test should now be reverted. >> > Yes! > > there are just two issues that are for pharo3 with fixes: > > https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… > Ok, so loading that one brakes *everything*. (the build did not get done, so no problem, other than a red build) I will revert tomorrow... Marcus

April 23, 2014