Hi,
I tried to export as png in Mondrian Renderer.
The first time, I changed the name in the open popup. The image did not create.
The second time, I do not change it, the image was created but, it is strange (see in attachment). Texts are not taken into account.
I am not sure it comes from Mondrian itself. I am using the Cog VM.
So can anyone try to export and to give feedback ?
Thank you.
---
Jannik Laval
Begin forwarded message:
> From: Simon Denier <Simon.Denier(a)inria.fr>
> Date: 19 août 2010 18:30:51 HAEC
> To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>
> Cc: Simon Denier <Simon.Denier(a)inria.fr>
> Subject: String insertion
>
> What's the best (most elegant/efficient...) way to insert a string into another string at a given index?
>
> Say I have the string 'Toto-Tata-Titi' and I want to build the string 'Toto-Tests-Tata-Titi'
>
> I could think of the following:
>
> | string sepIndex stream |
> string := 'Toto-Tata-Titi'.
> sepIndex := string indexOf: $-.
> stream :=String new writeStream.
> stream nextPutAll: (string copyFrom: 1 to: sepIndex).
> stream nextPutAll: 'Tests'.
> stream nextPutAll: (string copyFrom: sepIndex to: string size).
> ^ stream contents
>
>
> Any suggestion?
>
> --
> Simon
>
>
>
--
Simon
Begin forwarded message:
> From: Simon Denier <Simon.Denier(a)inria.fr>
> Date: 27 août 2010 14:06:42 HAEC
> To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>
> Cc: Simon Denier <Simon.Denier(a)inria.fr>
> Subject: Robust flatten for collection?
>
> Hi there
>
> A question to test your sagacity :)
>
> I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not.
>
>
> that is:
> #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6)
>
> #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6)
>
> #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6)
>
>
> Any idea about the best implementation for this?
>
>
> --
> Simon
>
>
>
--
Simon
Hi Nico
As you noticed, Moose is not (yet) made to load in a Pharo Core image. The full suite can only be loaded in a Pharo normal image.
Now it would be cool to have a special 'Core' configuration which could be loaded into a PharoCore for analysis. I know that Jannik worked on that a bit.
Especially since we now have good tools (dsm, blueprints) to take a look into that :)
So one dependency which we cant escape is the refactoring browser, because of the Smalltalk importer.
BTW, if you plan to use Moose regularly, the best is to subscribe to the mailing list:
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 27 août 2010, at 11:13, Nicolás Paez wrote:
> Hi, to workaround this issue, I started the setup again, loading first the RB package and after that Moose, that was enough to prevent the warning and everything went ok.
>
>
> Saludos!
> Nico.
> blog: nicopaez.wordpress.com
>
>
> On Fri, Aug 27, 2010 at 10:16 AM, Nicolas Paez <nicopaez(a)gmail.com> wrote:
> Hi,
>
> Summary
>
>
> Pharo image: PharoCore-1.1-11411
> VM: Squeak4.1.1.exe
> Moose: Loaded using Gofer script available in SqueakSource.
> Issue: it fails when trying to general a Smalltalk model
>
> Details
>
> This morning I have started by taking a clean PharoCore-1.1 image and launching the installation of Moose using the following command:
>
> Gofer new
> squeaksource: 'Moose';
> package: 'ConfigurationOfMoose';
> load.
> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault
>
> After some minutes the installation started I got the following warning message. It seems that Moose depends on the Refactoring Browser that is not present in the image.
>
> <moz-screenshot-78.png>
>
> I proceeded with the process and it finished I try to create a Smalltalk Model including the following packages:
> Kernel
> System-Support
> Compiler
> Collections
> When the model generation started I get the following error (the SmalltalkMethodVisitor class is not present in the image):
>
> <moz-screenshot-81.png>
>
>
>
> Regards,
> Nicolás
>
> _______________________________________________
> Lsehub-staff mailing list
> Lsehub-staff(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff
--
Simon
I am reviewing the code relating to invocations in Famix. I noticed the following.
FamixInvocation>>to
^ self receiver
Receiver can be a variable or a class, but can also be nil. This seemed a reasonable default at one time, because we do not necessarily now which method we are invoking (but again, we may not have a clear receiver to refer too).
However, with respect to other associations, consider:
FamixReference: from -> aMethod to -> aClass
FamixInheritance: form -> aClass to -> aClass
FamixAccess: from -> aMethod to -> aVariable
FamixInvocation: from -> aMethod to -> aVariable or a Class ???
(FamixExtension: from -> aPackage to -> aClass (well, this one is just future work :) )
It seems much more intuitive to have:
FamixInvocation: from -> aMethod to -> aMethod
Now of course, how do we refine that when we may have multiple candidates?
What would be a reasonable default?
FamixInvocation>>to
^ self candidates ifNotEmpty: [ self candidates any ]
FamixInvocation>>to
^ self isASureInvocation ifTrue: [ self candidates first ]
(sure invocation does not imply one candidate, so it may still break or be inconsistent)
FamixInvocation>>to
^ self candidates size = 1 ifTrue: [ self candidates first ]
or:
FamixInvocation>>to
^ self candidates
Actually, this one has my preference even if slightly different, because with the other choices we make hypothesis which are not clear.
FamixInvocation: from -> aMethod to -> a collection of Methods (candidates)
--
Simon
Hi,
Nicolas Paez tried to load Moose in a PharoCore.
But SmalltalkImporter depends on RB.
I think we should load RB in loadDefault.
Cheers,
Jannik
Begin forwarded message:
> From: Nicolas Paez <nicopaez(a)gmail.com>
> Date: August 27, 2010 10:16:50 GMT+02:00
> To: lsehub-staff(a)lists.gforge.inria.fr
> Subject: [Lsehub-staff] Moose installation issue
> Reply-To: notre liste <lsehub-staff(a)lists.gforge.inria.fr>
>
> Hi,
>
> Summary
>
>
> Pharo image: PharoCore-1.1-11411
> VM: Squeak4.1.1.exe
> Moose: Loaded using Gofer script available in SqueakSource.
> Issue: it fails when trying to general a Smalltalk model
>
> Details
>
> This morning I have started by taking a clean PharoCore-1.1 image and launching the installation of Moose using the following command:
>
> Gofer new
> squeaksource: 'Moose';
> package: 'ConfigurationOfMoose';
> load.
> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault
>
> After some minutes the installation started I got the following warning message. It seems that Moose depends on the Refactoring Browser that is not present in the image.
>
>
>
> I proceeded with the process and it finished I try to create a Smalltalk Model including the following packages:
> Kernel
> System-Support
> Compiler
> Collections
> When the model generation started I get the following error (the SmalltalkMethodVisitor class is not present in the image):
>
>
>
>
>
> Regards,
> Nicolás
> _______________________________________________
> Lsehub-staff mailing list
> Lsehub-staff(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/lsehub-staff
---
Jannik Laval
Hi. I am having a funny bug (I think). For a reason I don't know, some
properties (the ones that I think do not have any ocurrences), show a class
name instead of the selector.
Look and the attached picture. My example is something like
DistributionMap class >> anExample
^ (self onContainers: (self listOfCorePackagesNamesWithoutTests
collect: [ :each | (PackageInfo named: each) ]) elements: #classes
properties: [:element | element propertyInstancesStatesAndAmount ] )
render
open.
and Class >> propertyInstancesStatesAndAmount
propertyInstancesStatesAndAmount
| usedInstanceCount unusedInstanceCount |
usedInstanceCount := 0.
unusedInstanceCount := 0.
self isAbstractClass ifTrue: [
(UnusedObjectDiscoverer current primitiveGetUsedBit: self)
ifTrue: [ ^ #abstractUsedClass ]
ifFalse: [ ^ #abstractNotUsedClass].
].
self instanceCount = 0 ifTrue: [ ^ #noInstances].
self allInstancesDo: [:inst | (UnusedObjectDiscoverer current
primitiveGetUsedBit: inst) ifTrue: [ usedInstanceCount := usedInstanceCount
+ 1 ] ifFalse: [ unusedInstanceCount := unusedInstanceCount +1 ] ].
(unusedInstanceCount = 0) ifTrue: [ ^ #hasInstancesButNotUsed].
(usedInstanceCount between: 1 and: 10) ifTrue: [^
#usedInstancesBetween1And10].
(usedInstanceCount between: 11 and: 100) ifTrue: [^
#usedInstancesBetween11And100].
(usedInstanceCount between: 101 and: 1000) ifTrue: [^
#usedInstancesBetween101And1000].
(usedInstanceCount between: 1001 and: 10000) ifTrue: [^
#usedInstancesBetween1001And1000].
(usedInstanceCount between: 10001 and: 100000) ifTrue: [^
#usedInstancesBetween10001And100000].
(usedInstanceCount between: 100001 and: 1000000) ifTrue: [^
#usedInstancesBetween100001And1000000].
The last 3 properties: #usedInstancesBetween1001And1000,
#usedInstancesBetween10001And100000, #usedInstancesBetween100001And1000000
I guess they have no ocurrences, but, in the reference place in the DM, it
shows a class name instead of theor own name, lilke the rest.
I tried to track down the issue, but I didn't find anything.
Thanks for any help.
Mariano
Hello,
In order to provide a reporting system for pharo, I implemented some tools
over arki, build some concerns, work on way to save reports.
There still work to do, but you can already test it and give me feedback if
you want :):
Download the package 'MooseComputedConcerns' at:
www.squeaksource.com/MooseDemoReport.
A message will tell you to resolve depencies by first loading
'System-Benchmarks'.
As the concern about benchmarks is not finished you can choose to 'proceed'
(the benchmarkConcern will just not been working).
Otherwise you can load 'System-Benchmarks' from the same repository (allow
'block argument assignement' in the settings before).
Then you will be able, in the moose panel, to right click on a model and
open a arki reporter.
You can then play a bit with the browser.
pay attencion : load the last version of 'Refactoring-core' to be able to
use the LintRules-Concern
--------------------
Hi Alexander,
I updated my image today with the last version of Mondrian (541). I had previously (523).
The problem I noticed immediately is a terrible slowdown presenting popup views... They are used a lot in Torch for presenting diffs!!
Could you please find the problem?
Regards,
Veronica
Hello,
I would like to be able to update the title of a browser. Here is what I do
for example:
|browser |
browser := GLMTabulator new.
browser title: 'browser'.
browser openOn: nil.
browser title: 'new browser name'.
browser update.
The browser always display 'browser' as title.
Do you have any idea of how to do that ?
