Re: Scheme continuations vs Squeak continuations

Waow, thanks for the thorough explanation, it is very helpful !
now I have to dig in my scheme and see what I can do about it...

thanks again,

Stef

Re: Apology for offensive spam on annoncements list

Hi ken

It was clear that was not a Squeaker that wrote this shit.
Don't worry.

Stef

On Jan 25, 2009, at 9:04 PM, Ken Causey wrote:

> I apologize for this coming through on the announcements mailing list.
> I hope everyone realizes that I did not send this.  Several copies  
> were
> received purportedly 'from' various community members.  With the
> announcements list I have had a policy of moderating all messages,  
> even
> those from subscribers.  But in the last year or so I had begun to
> relaxen this somewhat by whitelisting anyone who sent messages
> regularly, this included myself.  Clearly this was a mistake and I  
> will
> now remove myself and everyone else from the whitelist and I will have
> to go back to moderating every single message.
>
> Again, my apologies,
>
> Ken Causey
>
> -------- Forwarded Message --------
> From: Lawrence Auster <ken <at> kencausey.com>
> Reply-To: ken <at> kencausey.com
> To: announcements <at> lists.squeakfoundation.org

Re: Apology for offensive spam on annoncements list

some communities do that already and this could be something to  
explore if we got more attacks.

stef

On Jan 26, 2009, at 12:09 PM, Janko Mivšek wrote:

> Another measure would be to authenticate e-mail sent to the lists more
> strongly, with signing it with PGP or S/MIME (digital certs). Signed
> emails would be tagged as completely trusted, while others would go  
> to a
> moderation list, or just tagged as untrusted.
>
> This requires additional discipline from us the senders of email of
> course and this is a major drawback of this approach. But it seems we
> will soon be forced to do that otherwise not too hard additional setup
> of our mail clients to support PGP or S/MIME mail signing.
>
> On the server side there is a project underway to upgrade Mailman list
> server (which we are using) to support such authentication:
>
>
> Secure List Server: Mailman, PGP and S/MIME
> http://non-gnu.uvt.nl/mailman-ssls/pgp-smime/talk/mailman-pgp-smime-talk.txt
> The Secure List Server: an OpenPGP and S/MIME aware Mailman
> http://non-gnu.uvt.nl/mailman-pgp-smime/
>
>
> Best regards
> Janko

Re: Apology for offensive spam on annoncements list

Hi Stef and Squeakers,

Stef said:
> It was clear that was not a Squeaker that wrote this shit.

Do you know or made any investigation about
 ideas related with been a Squeaker that serve
 to moredate/orientate/control the personality of
 a Squeaker?
 (e.g. my swiki have been violated many times by
 people that I know has knowledge about Squeak,
 no deep knowledge I must say, but approx. one
 year of "been a Squeaker" or so)

In the past I made studies trying to find
 a relation or pattern  in common between smalltalkers
 and I found more evidence of bad attitudes than
 good attitudes in practice (under human pov).
It was frustrating for me at that time, but it did not
 stop me.
I invested more efforts trying to understand a relation
 between the smalltalk architecture/design/formula
 and how it affects persons and how they evaluate
 the results of their actions (in reality, not in the systems
 they build with smalltalk).

I think that Stef have not had the intention to promote
 a dialog about this topic, but it is something I am
 interested in, as a way to understand the changes
 in Smalltalk related communities in the last decade

Re: Scheme continuations vs Squeak continuations

Stéphane Rollandin wrote:
> Julian Fitzell a écrit :
>> I'm assuming this is caused by Squeak's lack of full block closures.
>>
>> Does it work if you make "y" an instance variable instead of a local?
>>
>> Julian
> 
> 
> actually, trying the following does work in a workspace or a method:
> 
> | y |
> y _ Continuation currentDo: [:c | c].
> Transcript show: 1.
> Continuation currentDo: [:c | y value: c].
> Transcript show: 2.
> Continuation currentDo: [:c | y value: c].
> Transcript show: 3.
> 
> 
> so the problem occurs when y is an instance variable, while it works
> fine with a local variable (although if you try the code above in a
> workspace without declaring the | y | in the first line, it fails)

Indeed in GNU Smalltalk I get Squeak's behavior if y is a global, while
I get the correct behavior if y is a local.  You get the latter with

 Eval [
  |y|
  y _ Continuation currentDo: [:c | c].

Spam and short time solutions

Hi,

I read the thread from Paul Fernout and the answer from 
Janko. This is all heavy weight especially the PGP/SMIME
approach. I want to bring your attention to something that
is already existing and deals with the actual problem.

It is called Sender Policy Framework (SPF)[1] . It is basically
a method to be able to specify from which machine mails from
a certain domain are allowed to be sent.

My domain as an example has

norbert <at> cineflux:~$ dig TXT hartl.name

<snip/>

;; ANSWER SECTION:
hartl.name.		2018	IN	TXT	"v=spf1 mx -all"

So if I am sending a mail that is SPF aware it will check 
back this record and the record tells that my configured 
mail host is the only one allowed to send mail for that domain.
Fits quite good in the subscription system like this mailing
list.

FYI,

Norbert

The Weekly Squeak Summary No. 20: Aug 17, 2008 - Jan 31, 2009

Dear Squeakers,

welcome to this edition of The WeeklySqueakSummary, an irregular
traffic-dependent report on what's going on in the world of Squeak
based on the WeeklySqueak blog. Again, too many weeks have passed
since the last issue, but the number of items given below is still
rather small... is that good? Let's produce more news, preferably good
ones!

Highlights of the past weeks:

I'm not sure whether it's a good or a bad sign that some Gartner
analyst has come to the conclusion that Smalltalk is a good thing
[11]. Given what havoc analysts are capable of creating, it's probably
a double-edged sword. One can take out of this whatever one wants, I
think.

Anyway, on to more pleasant things.

About IDEs and GUIs: Trygve Reenskaug's DCI paradigm (read the reports
on his home page, it's worth it!) comes with an IDE concept, which he
has implemented in Squeak [6]. The Dependency Browser [12] allows for
keeping track of one's classes and their interactions. Mars [20] gives
you a native (read: Cocoa) GUI for Squeak on Mac OS X, and the Maui
GUI tool kit has been updated [19]. Oh, and IBM rediscovers their
likening for Smalltalk, integrating it with Eclipse [15] - I sincerely
hope the project won't be cancelled given the raging recent layoff
epidemic.

Alien FFI [18] is a lean and mean FFI implementation, coming from

Re: Scheme continuations vs Squeak continuations

> So, the setup is a group of three coroutines, with the execution
> threaded through them. The original invocation prints 1 and creates
> the second one. The second one prints 1 and switches back to the
> first. The first prints 2 and creates a third invocation, which prints
> 1 and jumps back to the first. The first prints 3 and completes. This
> is how "11213" is produced.

this made my day :) I just had to swap two statements in the 
implementation of 'let for my scheme to comply with the Mondo Bizarro 
puzzle.

now I wonder how many similar traps are still open in my code... looks 
like I can expect 'call/cc to to behave badly again some time, since I 
don't see a way to get a systematic overview of these subtle issues and 
fix them all.

what I can do is implement a call/cc stress test for my scheme. if 
people have little nasty piece of scheme code to submit, I would gladly 
include them in the test suite.

for those interested, the scheme for Squeak is available here:
http://www.zogotounga.net/comp/squeak/lispkit.htm

and the current tests are the #testCallCC serie in ULispWithLibTest. 
obviously I need more or them.

regards,

Stef

Re: Problems with FFI, SqueakDBX and MacOS

Squeaksource appears down...

Hi all. Squeaksource looks like it's down: no response (not connection  
refused) on port 80 despite the box pinging. Some firewall rule been  
changed?

Cheers,
Simon

Consider your responsibility to the environment - think before you print! 

******************************************************************************************************************************************
This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the
email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the
addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete
it from your system. Although this email and attachments are believed to be free of virus, or any other
defect which might affect any computer or IT system into which they are received and opened, it is the
responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by
Pinesoft for any loss or damage arising in any way from receipt or use thereof. *****************************************************************************************
 **************************************************


Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268
High Street, Waltham Cross, Herts, EN8 7EA