On 4 December 2012 10:32, <commits(a)source.squeak.org> wrote:
> Frank Shearar uploaded a new version of ReleaseBuilder to project The Inbox:
> http://source.squeak.org/inbox/ReleaseBuilder-fbs.77.mcz
>
> ==================== Summary ====================
>
> Name: ReleaseBuilder-fbs.77
> Author: fbs
> Time: 4 December 2012, 10:32:43.045 am
> UUID: fdbcec1f-a534-4070-b03f-1604faa4220a
> Ancestors: ReleaseBuilder-cmm.76
>
> Squeak 4.4 ReleaseBuilder.
>
> This renames ReleaseBuilderTrunk as ReleaseBuilderFor4dot3, and pulls some useful bits up to ReleaseBuilder for the 4.4 builder to reuse.
>
> =============== Diff against ReleaseBuilder-cmm.76 ===============
Note that the Welcome Workspace is completely unstyled. Chris has
given me a pointer on how to style it - use a Welcome Workspace - but
if there are any text-styling experts who can help us out, please do.
I can change the font of a piece of text easily enough in a Workspace
- right click and "set font" - but I see no way of making text bold
and underlined.
frank
I have made 4.4 releases for these packages:
OSProcess
CommandShell
TwosComplement
SystemTracing
TimeZoneDatabase
I also updated the VMMaker 'head' release to claim compatability with
Squeak 4.4. I do not intend to make a VMMaker release for Squeak 4.4,
because I would expect users to either be using the latest versions updated
from various repositories, or alternatively to be using some known version
of the sources obtained from squeakvm.org.
One annoyance encountered in these updates is that SqueakMap releases
apparently must be associated with one and only one image version. I think
this may be a change from the way SqueakMap used to work. In the case of
TwosComplement, I had to publish a complete new release for the identical
package version just make it appear 4.4 compatible, and in the case of
the various 'head' releases it means associating the bleeding edge version
with some specific version of the image, which presumably will become wrong
as the head version is advanced. Something tells me I'm misunderstanding
how this is supposed to work.
Dave
On Tue, 4 Dec 2012, commits(a)source.squeak.org wrote:
> Frank Shearar uploaded a new version of ReleaseBuilder to project The Inbox:
> http://source.squeak.org/inbox/ReleaseBuilder-fbs.78.mcz
>
> ==================== Summary ====================
>
> Name: ReleaseBuilder-fbs.78
> Author: fbs
> Time: 4 December 2012, 3:44:56.178 pm
> UUID: b4603341-7ff0-4a63-938f-160ddfdff273
> Ancestors: ReleaseBuilder-fbs.77
>
> 4.4 will ship with new network support (including IPv6) _disabled_ by default.
>
> =============== Diff against ReleaseBuilder-fbs.77 ===============
>
> Item was changed:
> ----- Method: ReleaseBuilderFor4dot4 class>>setPreferences (in category 'private') -----
> setPreferences
> Preferences
> installBrightWindowColors ;
> setPreference: #scrollBarsWithoutMenuButton toValue: true ;
> setPreference: #swapMouseButtons toValue: true ;
> setPreference: #annotationPanes toValue: true ;
> setPreference: #showSplitterHandles toValue: false ;
> setPreference: #showBoundsInHalo toValue: true ;
> setPreference: #alternateHandlesLook toValue: false ;
> setPreference: #roundedMenuCorners toValue: false ;
> + setPreference: #roundedWindowCorners toValue: false;
> + setPreference: #enableIpv6 toValue: false.
This won't work, because #enableIPv6 (note that it's not #enableIpv6) is a
"pragma" preference, so Preferences has no effect on it. The proper way to
change its value is to evaluate the following:
NetNameResolver enableIPv6: false.
Levente
P.S.: In 4.5 we should get rid of Preferences altogether (this should have
been done in 4.1 or 4.2 IMHO).
> - setPreference: #roundedWindowCorners toValue: false.
> PluggableButtonMorph roundedButtonCorners: false.
> FillInTheBlankMorph roundedDialogCorners: false.
> Workspace shouldStyle: false!
>
>
>
Call for Workshops
==================
In 2013, the European Conference on Object-Oriented Programming (ECOOP),
European Conference on Modelling Foundations and Applications (ECMFA)
and the European Conference on Software Architecture (ECSA) will be
collocated in Montpellier, France.
The 3 conferences will host an exciting array of workshops that
address a variety of topics in object-oriented technology,
Model-Driven Engineering and software architecture.
A workshop is a forum for exchanging ideas and theories that are still
in an evolutionary stage. Typically, a workshop will either address a
focused topic in depth or explore connections between one of the three
conferences' domains and other areas of interest.
ECOOP 2013, ECMFA 2013 and ECSA 2013 thus invite proposals for
workshops lasting half a day, one day or two days.
The workshops will be held Monday and Tuesday 1-2 July 2013.
Proposals
=========
A workshop proposal must be submitted as one PDF file.
It must include the following information, in this order:
* Name of the workshop (first page)
* Table of contents for the proposal (with page numbers)
* Duration of the workshop (half-day, full day, 2 days)
* Abstract: 150-200 words describing the workshop, suitable for the
conferences Web site
* Keywords and addressed domains.
* References to previous editions of the workshop (if any), including
name of host conference and number of participants to the workshop
each year
* Summary of the workshop format: e.g., refereed papers, and/or short
papers, and/or invited talks, and/or problem solving, and/or
brainstorming sessions. How will papers or other submissions be
reviewed?
* Description of how the workshop papers and results will be published
or otherwise disseminated (see the "Dissemination of Workshop Results"
section below)
* Preliminary Call For Workshop Papers describing the workshop's
focus, its main topics and its deadlines
* A (draft) list of the workshop PC members
* A list of the workshop organizers
* For each organizer of the workshop:
- name,
- affiliation
- contact information
- a brief biography (up to 200 words), focusing on the organizer's
expertise in the field and (if applicable) experience as a workshop
organizer
* Primary contact: identify one organizer as the primary contact
* Any special requirements that the workshop may have
Workshop Schedule Constraints
=============================
Each workshop will have to pay attention to the following timing constraints :
* the program must be made public before the early registration
deadline of the conferences; we thus expect you to make it available
around mid-may;
* the workshop must be able to consider submissions of papers rejected
by the conferences, and have these enter its reviewing process; we
thus expect you to make your submission deadline around mid-april;
* the workshop must send its Call For Papers at least one month before
submission deadline; we thus expect you to send your CFP around
mid-march;
Proposal Submission and Review
==============================
Workshop proposals should be submitted by email to the workshop chairs,
at ws-chairs-ec-montpellier-2013(a)inria.fr
Proposals will be reviewed by the workshop chairs.
Proposals will be selected based on their relevance to the conferences
aims, beneficiaries, and timely advances in their respective topics.
In particular, proposals will be evaluated according to the following
criteria:
- The potential to advance the state of research and practice
- The organizers' commitment to stimulate discussion at the workshop
- The organizers’ commitment to arrange for sensible digital and
permanent post-meeting proceedings
- The organizers' experience and ability to lead a successful workshop
- Timeliness and expected interest in the workshop topics
- The balance and synergy between the proposed workshops.
- The continuity of previous years workshops
*Workshop proposal deadline: January 10th*
*Workshop proposal notification: January 16th*
Workshop proposals may still be submitted after January 10th, till
February 15th, and will be evaluated with the same criteria. But in
addition these "late" proposals may only be accepted if their themes
do not interfere with those of already accepted workshops. We thus
strongly advise you to submit your workshop proposal as soon as
possible, and *before* January 10th.
Dissemination of Workshop Results
=================================
A proposal should clearly state how the results of the workshop, that
is the papers and other outcomes, will be made available to
participants and others, both before and after the workshop event. ACM
DL publications are encouraged.
Contact
=======
For additional information about this Call for Workshops, please
contact the workshop chairs at ws-chairs-ec-montpellier-2013(a)inria.fr.
An up-to-date version of this call for workshops may be found at:
http://info-web.lirmm.fr/ec-montpellier-2013/index.php/satelliteevents?id=1…
Workshop Chairs
===============
Olivier Zendra, INRIA Nancy - France
Reda Bendraou, Université Pierre et Marie Curie - France
Damien Cassou, Université Lille 1 - France
Stéphane Ducasse, INRIA Lille - France
http://news.squeak.org/
I've been posting The Weekly Squeak for six months. I never looked at
the statistics until today. A slow day for The Weekly Squeak is 70 views.
The weirdest thing is the number of views of old posts. I guess people
reach them by Google? The top ten posts for the last week are:
* = posted in the last month
Mmm...RaspberryPi *
136 views
Help Design The New squeak.org *
42 views
Squeak On Android
26 views
64-bit image *
18 views
Old Smalltalk Pics From PARC
11 views
JSSqueak -Smalltalk interpreter
6 views
Tangible User Interface for Squeak
6 views
Most of the views come from North America and northern Europe. There are
also views from Korea, Thailand, Japan, Australia, Spain, Columbia, and
Argentina.
Do robots scan blogs? Do they count as visitors? At any rate, more
people look at this than I would have suspected. By way of contrast and
to address the idea that visitors are just robots, The Squeak Oversight
Board blog has an average daily visitor count of eight views.
We can conclude two things: Squeakers may be low on the ground but all
around the world; and, the Raspberry Pi is the most viewed post for
awhile. Everybody likes ?.
Chris
Hello Eliot,
On Mon, Dec 3, 2012 at 1:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote:
>
> Hi Blake,
>
> On Mon, Dec 3, 2012 at 7:10 AM, Blake McBride <blake(a)mcbride.name> wrote:
>
>> Greetings,
>>
>> I tried to integrate Squeak to a C based application more than six years
>> ago. The project failed because we were not able to have our application
>> call Squeak, then have Squeak call the application, and then the
>> application call Squeak again recursively. An analysis of the Squeak VM
>> revealed a kernel design consisting of a lot of global variables - quite
>> unnecessarily. The unnecessary use of global variables over a localized
>> structure for example unnecessarily prevented the use of Squeak as an
>> extension language (unless you had no recursion). I spent several days
>> trying to re-structure the Squeak kernel but I kept running into problems
>> and just ran out of time.
>>
>> As a side note, that company I was with ended up making a lot of
>> investment in Scheme because we were easily able to integrate that language
>> with our application. Now, not only is Scheme used heavily within that
>> company but many of their clients use it too to customize their application.
>>
>> This brings me to my question, is COG reentrant?
>>
>
> Yes it is. It supports call-outs and call-ins. But currently there is no
> support for Cog to be packaged as a DLL. You have to start by calling C
> from Squeak.
>
I believe the regular Squeak supports call-outs and call-ins as well. The
real question is if it can be done recursively.
Can you initialize a new instance of the VM in the middle of a nested
call-in / callout?
Can an instance be cloned? Destroyed?
Thanks.
Blake
>
>
>
>
>> If not, as the author of COG, I would think it relatively easy to
>> restructure it to be so. Such a design capability can make a huge
>> difference to COG's acceptance to many. It may even be the reason to
>> switch to COG.
>>
>
> Yes indeed. The issue is of course funding to spend the time to make the
> necessary changes.
>
>
>> Just sharing some thoughts. Thanks.
>>
>> Blake McBride
>>
>> On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote:
>>
>>> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628.
>>>
>>> These fix a bug with pc mapping that could cause the Vm to crash on
>>> simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i|
>>> 1=1]). They also cause the instantiation primitives to pop all their
>>> arguments rather than assume their argument count is 0 or 1. More change
>>> info available in the directory.
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>