January 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Orientation

by Stephane Ducasse

Julien can you remind me to show you what Laura/Maximilliano did in MetaBorg? Stef On Mon, Jan 1, 2018 at 10:27 PM, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I developed a small framework to model orientation (north, east, south, > west). It defines some common operations that can be done on such objects > (turning, getting the opposite orientation, moving on n steps on a discrete > grid from a given position following certain orientation, etcâ¦). Also, it > supporte composed orientations (e.g. north-east). More details on GitHub > [1]. > > To install it: > > Metacello new > baseline: 'Orientation'; > repository: 'github://juliendelplanque/Orientation/repository'; > load > > This is not a lot but it is tested and I think it does its job well. So if > you need to model orientation, consider to use it. :-) > > If any ideas of what I could add to this API, Iâm interested. > > Regards, > > Julien > > [1]: https://github.com/juliendelplanque/Orientation > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille 1 > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >

Jan. 2, 2018

Solver for the Stable Marriage problem in Pharo

by Julien

Hello, Continuing to announce what I have. Some time ago I implemented a solver for the Stable Marriage problem [1] in Pharo [2]. Basically, in the stable marriage problem, you have two list of n element: a list of men and a list of women. Each person rank people of the other gender according to its preferences. The stable marriage algorithm find the best matches between men and women according to all rankings. It can be installed using: Metacello new baseline: 'StableMarriage'; repository: 'github://juliendelplanque/StableMarriage/repository'; load Regards, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

Jan. 2, 2018

Re: [Pharo-users] Is there a way to stop arrays sorting automatically?

by Andy Burnett

Henry said >>>> It's not broken, but certainly deserves a comment as to why it operates inline; In the general case, one should not use/care about any given permutation outside the block. Allocating n! instances of an n-sized array by default, is a bad tradeoff considering performance degradation for uses where n >> 3. In the first case, a user can add a simple #copy, while in the second case, a user would probably want/have to reimplement the method entirely. <<< Thanks, that makes perfect sense. I will have a go at adding a suitable comment. Cheers Andy >

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Esteban Lorenzano

> On 2 Jan 2018, at 18:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> if you have iceberg metacello integration enabledâ¦ Then it works on >> baselines, etc. > > Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still > got the error. I can't easily test in 7 because it depends on Magritte which > depends on Grease which doesn't seem to load yet. Maybe I can cobble > together a simpler test case. > > The Git error I mentioned in my OP was caused because `LGitRepository >> > clone:options:to:` is trying to clone > 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on > `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. > Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using > `MCBitbucketRepository` which is hardcoded. > > All of the above is with iceberg metacello integration enabled. yep. that seems to be a bug. Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Alistair Grant

Hi Sean, On 2 January 2018 at 18:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > EstebanLM wrote >> if you have iceberg metacello integration enabledâ¦ Then it works on >> baselines, etc. > > Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still > got the error. I can't easily test in 7 because it depends on Magritte which > depends on Grease which doesn't seem to load yet. Maybe I can cobble > together a simpler test case. This may not help, but... Pharo 7.0 Build information: Pharo-7.0+alpha.build.398.sha.52a28a857deec25612d302aba8ab09bdd6212b31 (32 Bit) I have Pillar loaded, which in turn loads: ConfigurationOfMagritte3-topa.126 Magritte-Model-SeanDeNigris.465 Magritte-Morph-SeanDeNigris.95 Magritte-Pharo3-Model-JohnCBorden.4 ConfigurationOfGrease-StephanEggermont.348 Grease-Core-JohanBrichau.97 Grease-Pharo30-Core-PavelKrivanek.22 The image was built about 4 days ago. HTH, Alistair > The Git error I mentioned in my OP was caused because `LGitRepository >> > clone:options:to:` is trying to clone > 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on > `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. > Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using > `MCBitbucketRepository` which is hardcoded. > > All of the above is with iceberg metacello integration enabled. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Sean P. DeNigris

EstebanLM wrote > if you have iceberg metacello integration enabledâ¦ Then it works on > baselines, etc. Strange. I did `Iceberg enableMetacelloIntegration: true.` first and still got the error. I can't easily test in 7 because it depends on Magritte which depends on Grease which doesn't seem to load yet. Maybe I can cobble together a simpler test case. The Git error I mentioned in my OP was caused because `LGitRepository >> clone:options:to:` is trying to clone 'git@bitbucket.org:nDeNigris/Quote-Me.git' based on `gitlab://SeanDeNigris/Quote-Me:master/repository` from the baseline spec. Earlier in the stack, `IceProviderRepositoryType >> mcRepository` is using `MCBitbucketRepository` which is hardcoded. All of the above is with iceberg metacello integration enabled. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Esteban Lorenzano

if you have iceberg metacello integration enabled (default in 7.0), the repository is resolved as part of iceberg and then it does not instances a MC*Repository but an IceMetacelloRepositoryAdaptor. Then it works on baselines, etc. Esteban > On 2 Jan 2018, at 17:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> MC*Repository is not iceberg but monticello api. > > Except it is extended by Iceberg-Adapters for #httpsUrl and #scpUrl! Also, > MCBitbucketRepository is hardcoded in > IceProviderRepositoryType>>#mcRepository, which was mangling the URL (off > the top of my head I assume because 'bitbucket' is longer than 'gitlab'). > This is all in #60528. I don't see how people could be using this unless > it's fixed in 7.0 (which it doesn't appear to be because there still seems > not to be an MCGitlabRepository) or they are using filetree:// or similar > URLs in their baselines. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 2, 2018

Re: [Pharo-users] [ANN] Orientation

by Henrik Sperre Johansen

Julien wrote > Hello, > > I developed a small framework to model orientation (north, east, south, > west). It defines some common operations that can be done on such objects > (turning, getting the opposite orientation, moving on n steps on a > discrete grid from a given position following certain orientation, etcâ¦). > Also, it supporte composed orientations (e.g. north-east). > > This is not a lot but it is tested and I think it does its job well. So if > you need to model orientation, consider to use it. :-) > > If any ideas of what I could add to this API, Iâm interested. A special class for holding a set of Orientations with associated value(s) <https://en.wikipedia.org/wiki/Wind_rose> could be a useful addition. In addition to the orientations/data itself, such a set would benefit from specifying both - An interpolation method to use * - An offset from physical orientation to set-local orientations. >From my experience, the following can be bug-prone scenarios if the above two are not part of such a model: - Querying a dataset for orientations not part of the original set**. Example: Your source data consists of 6 equally spaced data points, but in use, values for 8 equally spaced orientations are queried. - Representing/converting different types in a good way. Example: You model some entity where North(0@1) in design, is WSW in physical terms (presumably, because it makes the entity align more nicely with x/y axis), but source datasets are received in terms of Physical directions.*** - Redefine logical north of datasets with a preexisting logical north, while maintaining toPhysical(preRotDataset) = toPhysical(postRotDataset) **** Example: The physical orientation of the entity should be rotated, and you update the logical north to compensate, but the data should remain the same wrt. physical orientations. Cheers, Henry * Both for converting to a different set of orientations, and when queried for the value of a non-specified orientation ** With an interpolation method specified, you have the choice of tradeoff between speed (convert internal set to queried orientation, direct lookup), and adherence to original data set (keep internal set, interpolate each query) *** And avoiding physical -> model local orientation translation on each query can be nice, performance-wise **** Obviously, this is only troublesome if one does convert physical -> model local orientations -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Sean P. DeNigris

EstebanLM wrote > MC*Repository is not iceberg but monticello api. Except it is extended by Iceberg-Adapters for #httpsUrl and #scpUrl! Also, MCBitbucketRepository is hardcoded in IceProviderRepositoryType>>#mcRepository, which was mangling the URL (off the top of my head I assume because 'bitbucket' is longer than 'gitlab'). This is all in #60528. I don't see how people could be using this unless it's fixed in 7.0 (which it doesn't appear to be because there still seems not to be an MCGitlabRepository) or they are using filetree:// or similar URLs in their baselines. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 2, 2018

Re: [Pharo-users] Metacello with Git

by Esteban Lorenzano

> On 2 Jan 2018, at 16:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Vitor Medina Cruz wrote >>> I don't know for gitlab. > > It doesn't seem to work (in Pharo 6.1). `LGit_GIT_EEOF`. I see there is > MCBitbucketRepository but no MCGitlabRepository. MC*Repository is not iceberg but monticello api. Iceberg supports gitlab projects (both public and private servers) and I know there is people using them. If you are getting LGit_GIT_EEOF is likely a bug or a problem when declaring repoâ¦ but the information you are giving is not enough to know :) Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 2, 2018