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 |
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
|
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 |
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 |
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 |
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 |
> 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 |
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 |
> 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 |
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 |
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 |
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 |
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 |
> 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 |
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 |
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 |
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 |
>> 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 |
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 |
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 |
Free forum by Nabble | Edit this page |