Slow World Menu opening
by Alexandre Bergel
Hi!
When I open the world menu, the mouse cursor is intensively blinking, and opening the menu is _very slow_. This bugs has been around for a couple of weeks already. Am I the only one to see it?
I have checked the cause, and apparently the problem disappear by removing the use of “Cursor read showWhile:”. The following method:
-=-=-=-=-=-=-=-=-=
ImageReadWriter>>formFromStream: aBinaryStream
"Answer a ColorForm stored on the given stream. closes the stream"
| reader readerClass form |
readerClass := self readerClassFromStream: aBinaryStream.
reader := readerClass new on: aBinaryStream.
Cursor read showWhile:
[ form := reader nextImage.
reader close ].
^ form
-=-=-=-=-=-=-=-=-=
May be rewritten as:
-=-=-=-=-=-=-=-=-=
ImageReadWriter>>formFromStream: aBinaryStream
"Answer a ColorForm stored on the given stream. closes the stream"
| reader readerClass form |
readerClass := self readerClassFromStream: aBinaryStream.
reader := readerClass new on: aBinaryStream.
form := reader nextImage.
reader close.
^ form
-=-=-=-=-=-=-=-=-=
However, changing the cursor has been around for quite a long time. It is strange that the slow menu is surfacing only now.
Any idea why?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 years, 7 months
CFP: BENEVOL 2015 December 3-4 in Lille
by Anne Etien
Dear all,
We would like to cordially invite you to participate in BENEVOL 2015 in Lille, organised by the University of Lille 1 and Inria
The BENEVOL software evolution research seminar aims to gather junior and senior researchers from Belgium, the Netherlands, and neighboring countries to meet and to discuss new ideas, important problems and obtained research results in the field of software evolution.
Prospective speakers (junior or senior researchers or practitioners active in the field) are invited to submit an extended abstract (max. 2 A4 pages) of a talk. Based on these extended abstracts, the organization will construct an exciting program. The seminar particularly welcomes presentations of ongoing research or tools developed by PhD students. Senior researchers will provide the necessary feedback and lively discussions.
As every year, we will have invited talks by key researchers in the field
Attendance to BENEVOL 2015 is free (including lunch, coffee breaks, and dinner on the first day), but registration is required. The event will be hosted at Inria in Lille.
Important dates:
- Submission deadline: October 15th
- Registration deadline: November 15th
- Event: December 3rd and 4th
Extended abstracts (2 to 4 A4 pages) should be submitted using EasyChair:
https://easychair.org/conferences/?conf=benevol2015.
Proceedings will be published as a Inria technical report. Participants can still submit their work to other scientific venues.
Our kind sponsors enable free registration for the event:
- CRIStAL http://cristal.univ-lille.fr/
- GDR-GPL http://gdr-gpl.cnrs.fr/
- Inria www.inria.fr/centre/lille
- GT-GL http://www.cristal.univ-lille.fr/?rubrique26&id=5
Feel free to contact the organizers Nicolas Anquetil (nicolas.anquetil(a)univ-lille1.fr), Damien Cassou (damien.cassou(a)univ-lille1.fr) and Anne Etien (anne.etien(a)univ-lille1.fr).
Please redistribute the attached flyer among your network of software evolution researchers in the Netherlands, Belgium and neighboring countries.
Best regards,
Nicolas, Damien and Anne
7 years, 7 months
New features on MooseQuery
by Anne Etien
Hi,
Yesterday we developed two new features in MooseQuery:
- the toScope: method to go down in the containment tree. It is the opposite of atScope: that goes up. Both methods work the same way: ((classA queryIncoming: FAMIXInvocation) atScope: FAMIXClass) toScope: FAMIXMethod. This query uses the new API and returns the methods of the classes containing the methods sources of the incoming FAMIXInvocation of classA.
- the ability to query the MooseGroups. Thanks to this new feature, it is possible to query directly the model or any MooseGroup resulting from a selection or an operation (union, intersection, difference…) of several MooseGroups.
A full documentation’s coming, but certainly not before the end of the summer.
Cheers,
Jean-Christophe and Anne
7 years, 7 months
Re: [Pharo-dev] Re: Object new foo
by Vincent BLONDEAU
Hi Eliot,
Thanks for your help.
The problem has been resolved!
In fact a class was removed or renamed in Pharo, and the Moose debugger calls it just before the opening.
So it created an infinite loop, because the class wasn’t understood by the system, so it opened another debugger, etc….
Do you think something can be made to not break the image and so to break this infinite loop?
A solution may to open either another registered debugger, or the emergency debugger?
I can create an image with the problem if needed.
Vincent
De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Eliot Miranda
Envoyé : jeudi 20 août 2015 22:13
À : Pharo Development List
Cc : Moose-related development; Squeak Virtual Machine Development Discussion
Objet : Re: [Pharo-dev] [Moose-dev] Re: Object new foo
Hi Vincent,
does the image lock up when you execute Exception signal? The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo). So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image? I am willing to take a look at an image that contains the case. If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look.
On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote:
Hi,
On last Moose image, I debugged the VM and executed “Exception signal”.
I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:
static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);
static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);
The image is looping only when the debugger is launch on Error (not by launching it by the script below).
Maybe someone on the Pharo mailing list knows what is happening?
Thanks in advance,
Cheers,
Vincent
De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo
Hi Vincent,
You example will also kill the Pharo debugger :)
The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.
When you open the debugger you need to make sure the process
on which it is opened is suspended and can get terminated with no problem.
A different way to redo the example would be:
context := Context
sender: nil
receiver: {1 . 2 . 2}
method: (OrderedCollection>>#add:)
arguments: #(10).
process := Process
forContext: context
priority: Processor userInterruptPriority.
GTGenericStackDebugger openOn: (DebugSession process: process context: context).
There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.
Cheers,
Andrei
On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote:
Indeed. Maybe some tests has to be added..
But for now, it seems that the debugger is crashing the image… Not just by launching it:
GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context: (Context
sender: nil
receiver: {1 . 2 . 2}
method: (OrderedCollection>>#add: )
arguments: #(10)))
But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?
Cheers,
Vincent
De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo
This is weird that such bug can be introduced and no alarm is raised
Alexandre
Le 17 août 2015 à 08:03, Jan Kurš <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch> > a écrit :
Yep I had this problem (falled back to previous version), I suspected debugger being the reason.
Cheers Jan
On Sun, 16 Aug 2015 03:05 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com> > wrote:
in Moose 6.0 simply freezes.
Anyone else sees this?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,,,^..^,,,_
best, Eliot
7 years, 7 months
[Request]: Feedback for Issue #1130: Hook for Customized Presentation Constructors (e.g. Magritte)
by Sean P. DeNigris
>From https://github.com/moosetechnology/Moose/issues/1130 :
Right now, by default, a presentation constructor must be an annotated
method which takes a composite (and optional context) as arguments, and
configures a presentation.
For example:
gtInspectorStepsIn: composite
<gtInspectorPresentationOrder: 10>
composite list
title: 'Steps';
display: [ self children ]
While this serves the basic purpose, I found myself continuously duplicating
info which I had already described with Magritte, as in the description
mirroring the above:
descriptionChildren
<magritteDescription>
^ MAToManyRelationDescription new
accessor: #children;
label: 'Steps';
"..."
yourself
So, playing around, I created the following general purpose hook to give
more latitude in constructing presentations:
gtInspectorPresentationsIn: composite inContext: aGTInspector
"..."
eachPragma selector numArgs = 0
ifTrue: [
| configurationProvider |
configurationProvider := self perform: eachPragma
selector.
configurationProvider gtPresentation cull: composite
cull: aGTInspector cull: self ].
"..."
This enables you to get presentations almost for free by leaning on (in this
case) Magritte. The Magritte description gets a slight upgrade:
descriptionChildren
<magritteDescription>
<gtInspectorPresentationOrder: 10>
^ MAToManyRelationDescription new
accessor: #children;
label: 'Steps';
"..."
gtPresentation: [ :a | a list ];
yourself
#gtPresentation: sets default mappings, eliminating the original
duplication:
gtPresentation: aBlock
| wrapper |
wrapper := [ :composite :context :subject |
| presentation |
presentation := aBlock cull: composite cull: context.
presentation hasTitle ifFalse: [ presentation title: self label ].
presentation hasTransformation ifFalse: [ presentation display: (self
accessor read: subject) ] ].
self propertyAt: #gtPresentation put: wrapper
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Request-Feedback-for-Issue-1130-Hook-for-Customized...
Sent from the Moose mailing list archive at Nabble.com.
7 years, 7 months
Updating Configurations for Pharo 4.0
by Sean P. DeNigris
Is the Moose version loadable in Pharo4.0 now fixed? That is, how would one
back port a Moose feature into Pharo 4.0? The configurations already have
new versions which seem to have integrated Pharo 5.0-only features, but none
of these are in #pharo50 blocks.
I'm asking because Camp Smalltalkers are wanting to see a demo of the GT
Magritte extensions, but my projects are only loading in Pharo 4.0. Maybe
I'll just do a quick jdemo project in Pharo 5.0, but a lesser problem still
stands, which is that currently, I don't even know how to load my own
projects with these extensions without manually declaring specific Moose
package versions in my own configs, which is a hassle. Maybe I should make a
ConfigurationOfGlamourMagritteForPharo40?! Any suggestions are welcome.
Thanks :)
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Updating-Configurations-for-Pharo-4-0-tp4845070.html
Sent from the Moose mailing list archive at Nabble.com.
7 years, 7 months
SmaCC 2.0.5 released
by Thierry Goubier
Hi All,
I have released SmaCC 2.0.5, aligned on the main SmaCC[1] with a small fix
on the Java parser, a few additional parsers (Cucumber), the addition of
the Javascript parser, and continuous improvements on the performance and
source code coverage of SmaCC generated parsers (with many thanks to John
Brant and Don Roberts). The project is available on github[2]
[1] http://www.refactoryworkers.com/SmaCC.html
[2] https://github.com/ThierryGoubier/SmaCC
This release is targeted at Pharo4. All parsers should work on Pharo 5, but
the GUI doesn't work. Most parsers come with full AST generation and a
dedicated visitor for each, and support for native language refactoring.
To retrieve a specific parser, please use Metacello with the following
script:
Metacello new
baseline: 'SmaCC';
repository: 'github://ThierryGoubier/SmaCC:v2.0.5';
load: 'SmaCC-Javascript'
(SmaCC-Python, SmaCC-Java, SmaCC-Cucumber, etc...)
On Pharo4 only, to retrieve the full set (gui and tests), please use
Metacello with the following expressions:
Metacello new
baseline: 'SmaCC';
repository: 'github://ThierryGoubier/SmaCC:v2.0.5';
load
Regards,
Thierry
7 years, 7 months
Object new foo
by Alexandre Bergel
in Moose 6.0 simply freezes.
Anyone else sees this?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 years, 7 months
Roassal callbacks as events
by Peter Uhnák
Hi,
this is just an idea that's been bugging me for some time...
what if callbacks could be attached just like regular events?
e.g.
aBox when: TRExtentChanged do: [ :event | (self parentFor: aBox) rebuild ]
Is there benefit in having some events as events and some as callbacks?
Isn't event more versatile?
What do you think?
I should probably check how this is done in Bloc...
Peter
7 years, 7 months
Re: [Pharo-dev] Getting some tag in an HTML file
by Floyd May
If your scripts contain string literals with '<script>' or '</script>' in
them (I've seen this before), then your mileage may vary with Tudor's
approach. Also consider that script tags may have attributes, and those
attributes may have single or double quotes. Also, script tags may or may
not refer to javascript. Many javascript libraries use script tags for HTML
template sources, for instance. These tags you'd probably want to keep (and
perhaps follow the reference for the third):
<script type='text/javascript'> [code here] </script>
<script type='text/javascript'> document.write('<script
src="somewhere.js"></script>");</script> <!-- here be dragons! -->
<script type='text/javascript' src="path/to/javascript/source.js"></script>
However, something like this you might want to ignore:
<script type='text/html' id='someTemplate'>
<span>{{some template syntax}}</span>
</script>
If you can make some assumptions about what you're parsing you might be
able to adapt Tudor's solution to be more robust. However, if you're trying
for a general-purpose solution, I'd highly recommend using an existing HTML
parsing library, not an XML parser.
In general, parsing HTML as XML is the wrong approach. HTML is technically
not a subset of XML (closing tags aren't required), so most true XML
parsers are going to barf on it.
Some further reading:
https://en.wikipedia.org/wiki/Tag_soup
https://en.wikipedia.org/wiki/HTML5#XHTML5_.28XML-serialized_HTML5.29
I'm new to smalltalk so I can't recommend a library, but in Java I've used
Tag Soup and I've used Beautiful Soup in Python.
Hope this helps,
Floyd
On Fri, Aug 14, 2015 at 9:40 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
>
> You can also consider using island parsing, this very cool addition to
> PetitParser developed by Jan:
>
> beginScript := '<script>' asParser.
> endScript := '</script>' asParser.
> script := beginScript , endScript negate star flatten , endScript ==>
> #second.
> islandScripts := (script island ==> #second) star.
>
> If you apply it on:
>
> code := 'uninteresting part
> <script>
> some code
> </script>
> another
> uninteresting part
> <script>
> some other
> code
> </script>
> yet another
> uninteresting part
> '.
>
> You get:
> islandScripts parse: code
> ==> "#('some code' 'some other
> code')"
>
> Quite cool, no? :)
>
> Doru
>
>
> On Fri, Aug 14, 2015 at 1:31 AM, Alexandre Bergel <alexandre.bergel(a)me.com
> > wrote:
>
>
> Hi!
>>
>>>
>> Together with Nicolas we are trying to get all the <script …> … </script>
>> from html files.
>>
>>> We have tried to use XMLDOMParser, but many webpages are actually not
>> well formed, therefore the parser is complaining.
>>
>>>
>> Anyone has tried to get some particular tags from HTML files? This looks
>> like a classical thing to do. Maybe some of you have done it.
>>
>>> Is there a way to configure the parser to accept a broken XML/HTML
>> content?
>>
>>>
>> Cheers,
>>
>>> Alexandre
>>
>>> --
>>
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>
>>> Alexandre Bergel http://www.bergel.eu
>>
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>>
>>
>>
>>
>>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
> _______________________________________________
>
> Moose-dev mailing list
>
> Moose-dev(a)iam.unibe.ch
>
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
7 years, 7 months
