On Tue, Dec 2, 2008 at 2:11 PM, Hilaire Fernandes [EMAIL PROTECTED] wrote:
For Pharo to be a developer friendly environment, it is a must to
include these fixes, even waiting for a better solution, because
newbies will get burn there.
MC1.5 already fixes all issues and I think it would be
of course we won't do that.
Adrian
On Dec 2, 2008, at 10:52 , Stéphane Ducasse wrote:
+1
On Nov 30, 2008, at 4:39 PM, David Mitchell wrote:
Please don't include any font with ambiguous licensing! Wouldn't want
to bring back a fonts clause to the license!
On Sun, Nov 30, 2008 at 5:33 AM,
+1
On Nov 30, 2008, at 4:39 PM, David Mitchell wrote:
Please don't include any font with ambiguous licensing! Wouldn't want
to bring back a fonts clause to the license!
On Sun, Nov 30, 2008 at 5:33 AM, Adrian Lienhard [EMAIL PROTECTED]
wrote:
On Nov 30, 2008, at 10:35 , Stéphane Ducasse
No, installation of Magma through SqueakMap has MC1.5 as a
prerequisite, and it does not work on Pharo (I sent a previous post
but it was blocked because of the screenshot size, I will resent it
again)
Hilaire
2008/12/2 Damien Cassou [EMAIL PROTECTED]:
On Tue, Dec 2, 2008 at 2:11 PM, Hilaire
Yes apparently this is really on old windows.
stef
On Nov 30, 2008, at 4:47 PM, Gary Chambers wrote:
I've only seen that on existing windows in a fresh pickup of an
image release... Not seen it with new windows.
Tricky to track down what has caused the scrollbar frames to get
misadjusted
Hi Hilaire,
Which UI tools do you use? Omnibrowser or the old browser that is
shipped with the Core image.
Could you try to reproduce the problem in a newer version of Pharo?
(10050 is *very* old).
I'd like to take a look then. It's strange because we have been using
traits for two years
On Tue, Dec 2, 2008 at 3:43 PM, Hilaire Fernandes [EMAIL PROTECTED] wrote:
I try to load Magma with the patched MC (MonticelloConfigurations-cmm.44.mcz
and
Monticello-SR.315.mcz).
It results on an MNU error PastUpMorph does not undersand #description
This is the same bug as in the thread
Hi Hilaire,
Just as a side note, instead of sending a screenshot it is more useful
to send the SqueakDebug.log file that is created when a debugger pops
up in the same directory as your squeak image is located. This file
contains more information and requires less space.
Cheers,
Adrian
This is what I discovered after having discussed with Oscar.
Alexandre
On 1 Dec 2008, at 21:04, Chris Cunningham wrote:
Yes, these are necessary. They refer to an existsing file (old)
versus a non-existant file (the new prefixed methods). There are
several uses of it, but in my images
Ok this is true that we can load it after.
Installer was loaded by accident when I loaded Polymorph. It was
not there before we loaded Polymoph.
And it added a bunch of undfined references to classes not there.
Ah this should be fixed.
___
How Program History Can Improve Code Completion
Romain Robbes ~ Michele Lanza
ASE 2008 (12% acceptance) ~ to appear ~ IEEE CS, 2008
his pageweb is not up to date
I can send you his Phd
On Dec 1, 2008, at 12:50 PM, Damien Cassou wrote:
On Sun, Nov 30, 2008 at 7:16 PM, Stéphane Ducasse
[EMAIL
On 02.12.2008, at 10:41, Stéphane Ducasse wrote:
why do you unload Installer?
-- unloads packages: Installer, 39Deprecated, FlexibleVocablaries,
Pinesoft-Removals-EToys, ToolBuilder-MVC
Because I think that this is important to have it. May be a small
version: Installer and
I would really like to make the halos menu only showing up when we
press shift and this for all the system.
The halso are cool for mroph and duplicating window for example but
they get in our way.
yes
Hi guys
if you want to help simply.
Once etoy methods are removed from Morph, Object, PasteUpMorph
we will not rush and remove Etoy before we need to identify in Etoy
the
reference
made to MorphicExtras classes since some of them are etoyonly.
So if you have a little script I accept it
why do you unload Installer?
-- unloads packages: Installer, 39Deprecated, FlexibleVocablaries,
Pinesoft-Removals-EToys, ToolBuilder-MVC
Because I think that this is important to have it. May be a small
version: Installer and MCInstaller?
amazing when I see all the stuff that was in
still this is strange to invoke a comparison between MCDefinition and
World :)
On Dec 1, 2008, at 9:06 AM, Damien Cassou wrote:
On Sun, Nov 30, 2008 at 4:43 PM, Gary Chambers
[EMAIL PROTECTED] wrote:
Finding the modal morph is quite tricky (requests for a dialog not
specifically being tied
Okay, recheck with a fresh 10185, I can't remove the trait from my class.
What I do, from OB I change the class definition (remove the line with
the trait) then save. The trait just gets back. Is it the right way to
do it?
Which paper is appropriate to read, I saw several references in the squeak
it looks like traits can be removed with just writing uses: {}
Better check some documentation
Hilaire
2008/12/2 Hilaire Fernandes [EMAIL PROTECTED]:
Okay, recheck with a fresh 10185, I can't remove the trait from my class.
What I do, from OB I change the class definition (remove the line
On Dec 2, 2008, at 17:23 , Hilaire Fernandes wrote:
it looks like traits can be removed with just writing uses: {}
yes, that is the expected way to do it.
Better check some documentation
does this resolve your problem?
Adrian
Hilaire
2008/12/2 Hilaire Fernandes [EMAIL PROTECTED]:
In the modalMorph method of PSUIManager change the line in the middle to the
following...
receiver == World and: [sender selector == #handleEvent: or: [sender
selector == #findWindow:)
That should help things..
Regards, Gary.
- Original Message -
From: Hilaire Fernandes
2008/12/2 Adrian Lienhard [EMAIL PROTECTED]:
On Dec 2, 2008, at 17:23 , Hilaire Fernandes wrote:
it looks like traits can be removed with just writing uses: {}
yes, that is the expected way to do it.
Better check some documentation
does this resolve your problem?
So far it seems so.
jannik.laval.gmail wrote:
Hi all,
I would run this: (present in InstallerMonticellobasicView)
Installer ss project: 'Installer'; view: 'Installer-Core'.
But, I have an error: doesNotUnderstand: #definitions.
Can anyone help me ?
Thanks
Jannik
Fixed properly with latest Monticello1.5/1.6
Hi all
I was rereading our excellent forthcoming seaside book :)
And lukas wrote
To listen on port 80, the standard port used by the HTTP protocol, the
web server needs to run as root. Running a public service as root is
a huge security issue. Dedicated web servers such
-- Forwarded message --
From: Hilaire Fernandes [EMAIL PROTECTED]
Date: 2008/12/2
Subject: Trying to install Magma r41.1 throught Monticello installation 1.5+
To: Pharo Development pharo-project@lists.gforge.inria.fr,
[EMAIL PROTECTED]
I am CC to the Magma list as it may be more
ok, we need to take a closer look at this,
Do you remember which browser you used? If Omnibrowser, do you also
know which one?
Adrian
On Dec 2, 2008, at 13:58 , Stéphane Ducasse wrote:
Adrian
I got some problems during the last smalltalk party at paris.
my pair programmer quitted the image
I was using the package browser
Stef
On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote:
ok, we need to take a closer look at this,
Do you remember which browser you used? If Omnibrowser, do you also
know which one?
Adrian
On Dec 2, 2008, at 13:58 , Stéphane Ducasse wrote:
Adrian
I got
my question was more how can the VM be fixed :)
Stef
On Dec 2, 2008, at 10:00 PM, Lukas Renggli wrote:
I was rereading our excellent forthcoming seaside book :)
*lol*
And lukas wrote
To listen on port 80, the standard port used by the HTTP
protocol,
the
web server needs to
my question was more how can the VM be fixed :)
That's not a VM issue. It's not even a Smalltalk issue. It is just
common sense to not run anything reachable in public as root. There is
nothing to be fixed. As a developer you usually want to be able to
freely interact with the rest of the world
Unix blocks port 1 - 1024 for non root users. Running a Smalltalk
image as root is obviously a very bad idea, especially when used for
web services. Smalltalk is full of security holes (for example Object
class#readFrom: uses the compiler) that would allow a smart person
to gain root rights. It
reading about how unix programs drop privs it seems they can use
seteuid() to alter the state of the calling process. Not that the VM
needs to be 'fixed' but could the application be enhanced, using
OSProcess perhaps?, to drop privs in this way once port 80 has been
bound to? I read somewhere
Alexandre Bergel wrote:
Unix blocks port 1 - 1024 for non root users. Running a Smalltalk
image as root is obviously a very bad idea, especially when used for
web services. Smalltalk is full of security holes (for example Object
class#readFrom: uses the compiler) that would allow a smart
Yes, I read that. But is there any conceptual implication to have the
port 80 accessible only by root?
This looks like to be very arbitrary no?
Alexandre
On 2 Dec 2008, at 18:59, Janko Mivšek wrote:
Alexandre Bergel wrote:
Unix blocks port 1 - 1024 for non root users. Running a
I managed to load Seaside 2.9 in a Pharo image (current as of today). All
tests are green, but when I try to open http://localhost:8080/seaside/config,
I get MessageNotUnderstood: WAKomdispatchRequest:.
Any suggestions?
BTW - I just installed the changesets from [3].
-david
On Sat, Nov 22,
I don't know if it helps or not, but if I load the following:
(2008.10.01 17:13:50 22,203) MonticelloConfigurations-cmm.44.mcz
(2008.10.01 17:13:33 201,923) Monticello-SR.315.mcz
and then load Magma r41.1 from squeaksource.com/MagmaTester, it installed
fine (minus the eToys cautions).
Didn't
Hello all,
I grabbed 10183, hacked it into a one-click image on my Ubuntu box at
home, and found the Polymorph is indeed in the image. Frankly, I
suspect I might have missed it once before, possibly mistaking the
watery theme for the default look. It's great to see it included.
As Pharo 1.0
35 matches
Mail list logo
