amd 64 and gnu smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

amd 64 and gnu smalltalk

SeanTAllen
i was going to install gnu smalltalk on a debian etch system running  
on a 64 bit amd processor via apt-get and noticed that there is no  
package for that processor.
is there a technical reason for this? if i build from source, will it  
not work? if building from source is going to result in a buggy  
implementation, i'd rather not waste the time... just want to check  
before i go about converting all my ruby administration scripts to gnu  
smalltalk.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: amd 64 and gnu smalltalk

ZuLuuuuuu
Sean Allen <sean <at> monkeysnatchbanana.com> writes:

>
> i was going to install gnu smalltalk on a debian etch system running  
> on a 64 bit amd processor via apt-get and noticed that there is no  
> package for that processor.
> is there a technical reason for this? if i build from source, will it  
> not work? if building from source is going to result in a buggy  
> implementation, i'd rather not waste the time... just want to check  
> before i go about converting all my ruby administration scripts to gnu  
> smalltalk.
>


I don't know much about packaging but I guess the reason is that nobody prepared
the 64 bit package "yet". So, I don't see a reason for GNU Smalltalk not to work
on 64 bit systems when you compile it.

Though, I don't think that converting all of your Ruby administration scripts
into GST is a good idea. GST is not as stable as Ruby or does not have extra
libraries as much as Ruby has etc... Maybe you should first try some
experimental administration scripts and convert the rest if you are satisfied.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Canol Gökel
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

SeanTAllen

On Jan 5, 2009, at 1:50 AM, Canol Gokel wrote:

> Sean Allen <sean <at> monkeysnatchbanana.com> writes:
>
>>
>> i was going to install gnu smalltalk on a debian etch system running
>> on a 64 bit amd processor via apt-get and noticed that there is no
>> package for that processor.
>> is there a technical reason for this? if i build from source, will it
>> not work? if building from source is going to result in a buggy
>> implementation, i'd rather not waste the time... just want to check
>> before i go about converting all my ruby administration scripts to  
>> gnu
>> smalltalk.
>>
>
>
> I don't know much about packaging but I guess the reason is that  
> nobody prepared
> the 64 bit package "yet". So, I don't see a reason for GNU Smalltalk  
> not to work
> on 64 bit systems when you compile it.
>
> Though, I don't think that converting all of your Ruby  
> administration scripts
> into GST is a good idea. GST is not as stable as Ruby or does not  
> have extra
> libraries as much as Ruby has etc... Maybe you should first try some
> experimental administration scripts and convert the rest if you are  
> satisfied.
>

I tested them all on a 32 bit system a couple weeks back and had no  
issues
but, thanks for the advice.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Paolo Bonzini-2
In reply to this post by ZuLuuuuuu

> I don't know much about packaging but I guess the reason is that nobody prepared
> the 64 bit package "yet". So, I don't see a reason for GNU Smalltalk not to work
> on 64 bit systems when you compile it.

Have you checked testing/unstable?

> Though, I don't think that converting all of your Ruby administration scripts
> into GST is a good idea. GST is not as stable as Ruby or does not have extra
> libraries as much as Ruby has etc... Maybe you should first try some
> experimental administration scripts and convert the rest if you are satisfied.

It depends on what the scripts do...  If it is an experiment, why not
(Stephen did the same and he had some LDAP functions bindings in the
process).  Anyway, if so I suggest compiling 3.1 from source: it's not
going to be buggy, and the File/Directory methods were rewritten (so
they are better, and you don't have to forward-port them in the future).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Paolo Bonzini-2
In reply to this post by SeanTAllen
>> GST is not as stable as Ruby or does not have extra
>> libraries as much as Ruby has etc... Maybe you should first try some
>> experimental administration scripts and convert the rest if you are
>> satisfied.
>
> I tested them all on a 32 bit system a couple weeks back and had no issues
> but, thanks for the advice.

I think GST is quite stable now.  The external libraries might be a
problem, but Sean knows what he's doing. :-)

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Stephen-71
In reply to this post by SeanTAllen

>>
>> Though, I don't think that converting all of your Ruby administration
>> scripts
>> into GST is a good idea. GST is not as stable as Ruby or does not have
>> extra
>> libraries as much as Ruby has etc... Maybe you should first try some
>> experimental administration scripts and convert the rest if you are
>> satisfied.
>>
>
> I tested them all on a 32 bit system a couple weeks back and had no issues
> but, thanks for the advice.
>

I've been scripting in GST on Linux (Gentoo and CentOS) and
also Mac OS X for the past year. Prior to that I used Ruby. Most of the
Linux boxen are 32 bit systems, with some 64 bit systems also.
Some of the scripts I've written are at
http://smalltalk.gnu.org/wiki/Examples

There has been the occasional minor bug and Paolo has nailed any issues
pretty quick (outstanding is a bug with the IMAP library which won't
read emails with attachments, and have found an issue with Seaside in
GST on 64 bit systems).

As to Libraries, the main thing I'm missing is an LDAP library which
I've got around calling ldapsearch and ldapmodify. I started writing a
wrapper around the C LDAP API with Paolo's help. What we got done was
working until I got in contact with the developer of the Squeak
LDAPLayer library and decided to port LDAPLayer to GST when I get some
time. ...
(Sometime I plan to document the LDAP API wrapper work we did as it will
probably be helpful to someone to have an example)

Version changes have been friendly, I started when GST was at 2.x and it
is at 3.1 and all my original scripts work with no changes.

I actually started using GST because I wanted to do Seaside programming
in Squeak and had very little spare time in 2008 - using GST was a way
of getting Smalltalk experience in my day job.  If I look back, I'd make
the same choice again. I've found GST stable and quick to develop in,
and if something does break, then GST dumps a stack trace with line
numbers which is very helpful.

Regards
Stephen



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Stephen-71

> and if something does break, then GST dumps a stack trace with line
> numbers which is very helpful.
By this I mean if one of my scripts breaks (not a fault in GST). I'm
thinking of Ruby which when I used it at least, could just drop out with
little to say what went wrong.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

SeanTAllen
In reply to this post by Paolo Bonzini-2

On Jan 5, 2009, at 4:06 AM, Paolo Bonzini wrote:

>>
>> I don't know much about packaging but I guess the reason is that  
>> nobody prepared
>> the 64 bit package "yet". So, I don't see a reason for GNU  
>> Smalltalk not to work
>> on 64 bit systems when you compile it.
>
> Have you checked testing/unstable?

No, I didn't- I only ever use the stable branch. I was tired when i  
asked the question
and completely missed that the last stable gnu smalltalk in debian  
stable is a 2.1.x
version.  Usually they are good about keeping packages for gnu stuff  
up to date,
must not have a maintainer for the gnu smalltalk anymore.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Paolo Bonzini-2

> No, I didn't- I only ever use the stable branch. I was tired when i
> asked the question
> and completely missed that the last stable gnu smalltalk in debian
> stable is a 2.1.x
> version.  Usually they are good about keeping packages for gnu stuff up
> to date,
> must not have a maintainer for the gnu smalltalk anymore.

No, there is one (Thomas Girard).  ISTR that testing is okay, probably
3.0.x or 3.1, because GNU Smalltalk missed by very little the deadline
for the last stabilization.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Thomas Girard
Hello all,

Indeed I maintain Debian GNU Smalltalk packages, and the version in stable is really old.

Would you be interested in 3.1 backport for etch?

Regards,

Thomas

----- Mail Original -----
De: "Paolo Bonzini" <[hidden email]>
Ă€: "Sean Allen" <[hidden email]>
Cc: [hidden email]
Envoyé: Lundi 5 Janvier 2009 17:05:36 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [Help-smalltalk] Re: amd 64 and gnu smalltalk


> No, I didn't- I only ever use the stable branch. I was tired when i
> asked the question
> and completely missed that the last stable gnu smalltalk in debian
> stable is a 2.1.x
> version.  Usually they are good about keeping packages for gnu stuff up
> to date,
> must not have a maintainer for the gnu smalltalk anymore.

No, there is one (Thomas Girard).  ISTR that testing is okay, probably
3.0.x or 3.1, because GNU Smalltalk missed by very little the deadline
for the last stabilization.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

SeanTAllen
While I use debian all the time and have for years, the package  
terminology is something I've never bothered to learn.

So question, what is a backport?

On Jan 5, 2009, at 12:43 PM, [hidden email] wrote:

> Hello all,
>
> Indeed I maintain Debian GNU Smalltalk packages, and the version in  
> stable is really old.
>
> Would you be interested in 3.1 backport for etch?
>
> Regards,
>
> Thomas
>
> ----- Mail Original -----
> De: "Paolo Bonzini" <[hidden email]>
> À: "Sean Allen" <[hidden email]>
> Cc: [hidden email]
> EnvoyĂ©: Lundi 5 Janvier 2009 17:05:36 GMT +01:00 Amsterdam /  
> Berlin / Berne / Rome / Stockholm / Vienne
> Objet: Re: [Help-smalltalk] Re: amd 64 and gnu smalltalk
>
>
>> No, I didn't- I only ever use the stable branch. I was tired when i
>> asked the question
>> and completely missed that the last stable gnu smalltalk in debian
>> stable is a 2.1.x
>> version.  Usually they are good about keeping packages for gnu  
>> stuff up
>> to date,
>> must not have a maintainer for the gnu smalltalk anymore.
>
> No, there is one (Thomas Girard).  ISTR that testing is okay, probably
> 3.0.x or 3.1, because GNU Smalltalk missed by very little the deadline
> for the last stabilization.
>
> Paolo
>
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Re: amd 64 and gnu smalltalk

Paolo Bonzini-2
Sean Allen wrote:
> While I use debian all the time and have for years, the package
> terminology is something I've never bothered to learn.
>
> So question, what is a backport?

An unofficial packaging of a newer version, meant to be installed on top
of stable.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

GNU Smalltalk and unix integration..

SeanTAllen
In reply to this post by SeanTAllen
>>
>>
>> I don't know much about packaging but I guess the reason is that  
>> nobody prepared
>> the 64 bit package "yet". So, I don't see a reason for GNU  
>> Smalltalk not to work
>> on 64 bit systems when you compile it.
>>
>> Though, I don't think that converting all of your Ruby  
>> administration scripts
>> into GST is a good idea. GST is not as stable as Ruby or does not  
>> have extra
>> libraries as much as Ruby has etc... Maybe you should first try some
>> experimental administration scripts and convert the rest if you are  
>> satisfied.
>>
>
> I tested them all on a 32 bit system a couple weeks back and had no  
> issues
> but, thanks for the advice.

Ah, actually I missed two... both of which need to interact with the  
filesystem permission,
in particular dealing with file owner and group. I cant find anything  
to do that.
Does it exist right now or should I start my real GNU Smalltalk  
learning by learning the C interface
and adding that functionality?



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

Paolo Bonzini-2

> Ah, actually I missed two... both of which need to interact with the
> filesystem permission,
> in particular dealing with file owner and group. I cant find anything to
> do that.

No, there is none. :-)  But it is a small patch that can make its way
into 3.1.1.  Wait a couple hours.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

SeanTAllen

On Jan 7, 2009, at 2:40 AM, Paolo Bonzini wrote:

>
>> Ah, actually I missed two... both of which need to interact with the
>> filesystem permission,
>> in particular dealing with file owner and group. I cant find  
>> anything to
>> do that.
>
> No, there is none. :-)  But it is a small patch that can make its way
> into 3.1.1.  Wait a couple hours.

That I can do. Even easier than doing it myself although, not as good  
for the learning.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

Paolo Bonzini-2
Sean Allen wrote:

>
> On Jan 7, 2009, at 2:40 AM, Paolo Bonzini wrote:
>
>>
>>> Ah, actually I missed two... both of which need to interact with the
>>> filesystem permission,
>>> in particular dealing with file owner and group. I cant find anything to
>>> do that.
>>
>> No, there is none. :-)  But it is a small patch that can make its way
>> into 3.1.1.  Wait a couple hours.
>
> That I can do. Even easier than doing it myself although, not as good
> for the learning.

Yes, I know -- sorry.  I would have helped you DIY for, say chmod.
However the API in this case was a little different between chmod(2) and
the Smalltalk classes (chmod wants uids/gids, not names), and I was
afraid you'd go through too many iterations or frustrations or both.

I also took the occasion to add another tiny feature, as I wrote in the
other message, namely an implementation of "chmod -R"/"chown -R"/"touch
-R" (the latter actually does not exist in coreutils).

You can look at the patch I sent, it only adds lines so it should be
easy to read.  If you want to summarize your findings in a blog post on
http://smalltalk.gnu.org/ or something like that, I'll be glad to read
it and comment it to aid your learning.

Thanks,

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

SeanTAllen

On Jan 7, 2009, at 8:49 AM, Paolo Bonzini wrote:

> Sean Allen wrote:
>>
>> On Jan 7, 2009, at 2:40 AM, Paolo Bonzini wrote:
>>
>>>
>>>> Ah, actually I missed two... both of which need to interact with  
>>>> the
>>>> filesystem permission,
>>>> in particular dealing with file owner and group. I cant find  
>>>> anything to
>>>> do that.
>>>
>>> No, there is none. :-)  But it is a small patch that can make its  
>>> way
>>> into 3.1.1.  Wait a couple hours.
>>
>> That I can do. Even easier than doing it myself although, not as good
>> for the learning.
>
> Yes, I know -- sorry.  I would have helped you DIY for, say chmod.
> However the API in this case was a little different between chmod(2)  
> and
> the Smalltalk classes (chmod wants uids/gids, not names), and I was
> afraid you'd go through too many iterations or frustrations or both.
>
> I also took the occasion to add another tiny feature, as I wrote in  
> the
> other message, namely an implementation of "chmod -R"/"chown -
> R"/"touch
> -R" (the latter actually does not exist in coreutils).
>
> You can look at the patch I sent, it only adds lines so it should be
> easy to read.  If you want to summarize your findings in a blog post  
> on
> http://smalltalk.gnu.org/ or something like that, I'll be glad to read
> it and comment it to aid your learning.
>

I never saw the patch. It wasn't included in the last message.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

Paolo Bonzini-2

>> You can look at the patch I sent, it only adds lines so it should be
>> easy to read.
>
> I never saw the patch. It wasn't included in the last message.

http://permalink.gmane.org/gmane.comp.lang.smalltalk.gnu.general/3661

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

SeanTAllen

On Jan 7, 2009, at 10:03 AM, Paolo Bonzini wrote:

>
>>> You can look at the patch I sent, it only adds lines so it should be
>>> easy to read.
>>
>> I never saw the patch. It wasn't included in the last message.
>
> http://permalink.gmane.org/gmane.comp.lang.smalltalk.gnu.general/3661
>

Ah... very nice...
Can we start a touch of learning with a question?
What is the recursive_depth code?
Link to existing explanations quite fine.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk and unix integration..

Paolo Bonzini-2
Sean Allen wrote:

>
> On Jan 7, 2009, at 10:03 AM, Paolo Bonzini wrote:
>
>>
>>>> You can look at the patch I sent, it only adds lines so it should be
>>>> easy to read.
>>>
>>> I never saw the patch. It wasn't included in the last message.
>>
>> http://permalink.gmane.org/gmane.comp.lang.smalltalk.gnu.general/3661
>>
>
> Ah... very nice...
> Can we start a touch of learning with a question?
> What is the recursive_depth code?
> Link to existing explanations quite fine.

It's much more low-tech than you'd imagine. :-)  In particular, it does
not have anything to do with Smalltalk (even though it enables an
optimization used by the kernel/VFS.st part of the patch).  And it's
ad-hoc for chown (the variable is static), so there is no existing
explanation. :-)

I made chown take user/group names instead of uid/gid numbers, but the
getgrnam and getpwnam routines are potentially very slow, because they
have to lookup /etc/passwd and /etc/groups.  As a quick optimization,
I've made a simple 1-entry cache that should only be used while doing

  (File name: 'dir') all owner: 'root'

(that's "chown -R root dir") and not during normal single-file
operation.  recursive_depth refers to "usage of my_chown from recursive
operations, it doesn't have to do with the innards of the interpreter.
The cache is started by calling my_chown(NULL, "user", "group") and
ended by my_chown(NULL, NULL, NULL), which respectively increment and
decrement recursive_depth.  I made it a counter instead of a boolean in
case multiple Smalltalk threads are doing different recursive chowns at
the same time.

In this case, the cache will not eliminate all getgrnam/getpwnam calls
because it's only 1-entry, but it will eliminate most of them.  In order
to speed up the code a bit further if there is contention, I call
setgroupent/setpassent at the beginning of recursive operations (when
recursive_depths goes from 0 to 1), and endgrent/endpwent at the end
(when it goes from 1 to 0):

     The setgroupent() function opens the [/etc/groups] file.  If
     stayopen is non-zero, file descriptors are left open, signifi-
     cantly speeding functions subsequent calls.  This functionality is
     dangerous for long-running as the group file may be updated.

For this reason endgrent/endpwent are called to close the file when the
recursive updating is finished.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
12