Menu
▾
▴
pythoncard-users
|
From: Nextime <ne...@ne...> - 2008-11-26 22:22:47
|
Hello all. As a demostration that nothing is moving here, after few posts saying "i don't agree with a fork", nothing more on this list or in developement of PythonCard. So, with all my thanks for all original developers of pythoncard for the base code of the new project, i have forked pythoncard. The new project will be called "Picard", and the developemed will be completely separated from the one of pythoncard. Picard is a name dedicated to the Cpt. Picard from StarTrek TNG, cause of the assonance ( at least in my language ) with "PyCard". actually i have a pre-release on my svn, at https://svn.nexlab.it/medianix/packages/main/pythoncard/trunk whit those changed from the original codebase: - Patched with changes from Alex Tweedly for sizers - Fixed some bugs in the layoutEditor, first of all now buttons can be dragged also on GTK based platforms, and other minor fixes - added a new component: CollapsiblePane The future roadmap, at least for now is (in sparse order): - Change the name of the package (this will be the first thing to do!). - dropping out codeEditor, resourceEditor, experimentalResourceEditor, oneEditor, findfiles, standaloneBuilder - make layoutEditor the default (and peraps unique) resource file editor - Improve layoutEditor in many ways - add many other components - cleaning the code - change resource files to an XML format - let's use something like a zip container as resource to embed also images and so on - make layoutEditor produce also a python class to be derived in the main program Any help and/or contributor will be welcome in the new project, this will be the last post here from mine about this, any new post about Picard will be done in the new mailing list on the project trac site, http://trac.medianix.org/wiki/PyCard (the name will change to Picard soon) Franco. -- Franco Lanza My blog: http://www.nexlab.it email: ne...@ne... Fax/Tel: +39 0331 682151 Cell: +39 339 8125940 Busto Arsizio (VA) - Italy ----------------------------------- NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- |
|
From: Nextime <ne...@ne...> - 2008-11-26 22:43:12
|
Hello all. As a demostration that nothing is moving here, after few posts saying "i don't agree with a fork", nothing more on this list or in developement of PythonCard. So, with all my thanks for all original developers of pythoncard for the base code of the new project, i have forked pythoncard. The new project will be called "Picard", and the developemed will be completely separated from the one of pythoncard. Picard is a name dedicated to the Cpt. Picard from StarTrek TNG, cause of the assonance ( at least in my language ) with "PyCard". actually i have a pre-release on my svn, at https://svn.nexlab.it/medianix/packages/main/pythoncard/trunk whit those changed from the original codebase: - Patched with changes from Alex Tweedly for sizers - Fixed some bugs in the layoutEditor, first of all now buttons can be dragged also on GTK based platforms, and other minor fixes - added a new component: CollapsiblePane The future roadmap, at least for now is (in sparse order): - Change the name of the package (this will be the first thing to do!). - dropping out codeEditor, resourceEditor, experimentalResourceEditor, oneEditor, findfiles, standaloneBuilder - make layoutEditor the default (and peraps unique) resource file editor - Improve layoutEditor in many ways - add many other components - cleaning the code - change resource files to an XML format - let's use something like a zip container as resource to embed also images and so on - make layoutEditor produce also a python class to be derived in the main program Any help and/or contributor will be welcome in the new project, this will be the last post here from mine about this, any new post about Picard will be done in the new mailing list on the project trac site, http://trac.medianix.org/wiki/PyCard (the name will change to Picard soon) Franco. -- Franco Lanza My blog: http://www.nexlab.it email: ne...@ne... Fax/Tel: +39 0331 682151 Cell: +39 339 8125940 Busto Arsizio (VA) - Italy ----------------------------------- NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- |
|
From: Mark C. <ma...@ma...> - 2008-11-27 08:19:48
|
Hello. On Wed, Nov 26, 2008 at 5:41 PM, Nextime <ne...@ne...> wrote: > So, with all my thanks for all original developers of pythoncard > for the base code of the new project, i have forked pythoncard. I love Pythoncard, and as a casual hobby programmer, PythonCard has given me an easy to use way make GUIs for my Python programs. It's helped me transition from Visual Basic to Python (moving away from VB, by far the biggest obstacle is replacing the superb interface building tools). Looking for a quick and easy way to do a GUI with Python, PythonCard came out way ahead of Glade/QT/wxWidgets/etc. I do think there is PythonCard development going on, but it's no doubt done in whatever spare time the developers have. However, where I think a lot of end users have lost confidence in the project is simply that despite whatever development may be happening, there hasn't been a history of frequent releases of executable installers. Rather than very infrequent releases with major changes, end users prefer frequent releases with incremental improvements. > - dropping out codeEditor, resourceEditor, Please don't drop codeEditor... I quite liked it as part of the package; very useful. > - change resource files to an XML format I know that XML is the cool thing these days, but whatever you do, please keep the files in a simple enough format that they can be hand-edited if necessary. I liken it to HTML versus CSS... HTML you can do by hand, and it's simple. CSS is so complex that it's barely human-readable. It may be great if you're using expensive proprietary software for web development, but it's an example of complexity going beyond the bounds of being beneficial, and instead becoming a burden. Beyond that, I haven't had an itch to scratch with programming for a while, so I can't comment too much on Pythoncard's current state. Although I'll probably be updating my Python install to 2.6 and checking that my software still works... I recall that when reading that they planned to break compatibility with past code in Python 2.6 that it sounded like a really boneheaded idea... hopefully I'll find that it was only obscure code that was going to become incompatible. Mark |
|
From: Andy T. <an...@ha...> - 2008-11-27 08:58:36
|
Mark Carter wrote: > Hello. > > On Wed, Nov 26, 2008 at 5:41 PM, Nextime <ne...@ne...> wrote: >> So, with all my thanks for all original developers of pythoncard >> for the base code of the new project, i have forked pythoncard. > And good luck to Franco with his new project. > I love Pythoncard, and as a casual hobby programmer, PythonCard has > given me an easy to use way make GUIs for my Python programs. It's > helped me transition from Visual Basic to Python (moving away from VB, > by far the biggest obstacle is replacing the superb interface building > tools). Looking for a quick and easy way to do a GUI with Python, > PythonCard came out way ahead of Glade/QT/wxWidgets/etc. > > I do think there is PythonCard development going on, but it's no doubt > done in whatever spare time the developers have. However, where I > think a lot of end users have lost confidence in the project is simply > that despite whatever development may be happening, there hasn't been > a history of frequent releases of executable installers. Rather than > very infrequent releases with major changes, end users prefer frequent > releases with incremental improvements. > +1, and a fair call. It has also generally relied on the project benevolent dictator being interested and making the changes he wanted to make. As I previously stated, if someone wants to step up and provide patches or new code for PythonCard we have the ability to let them become project developers on SourceForge. Given a sufficient track record of contribution it should also be possible to make other people project administrators. As a wise man once said - show us the code. > >> - dropping out codeEditor, resourceEditor, > > Please don't drop codeEditor... I quite liked it as part of the > package; very useful. > > >> - change resource files to an XML format > > I know that XML is the cool thing these days, but whatever you do, > please keep the files in a simple enough format that they can be > hand-edited if necessary. I liken it to HTML versus CSS... HTML you > can do by hand, and it's simple. CSS is so complex that it's barely > human-readable. It may be great if you're using expensive proprietary > software for web development, but it's an example of complexity going > beyond the bounds of being beneficial, and instead becoming a burden. > +1, we talked about this over the life of the project and could never come up with a compelling reason to change the current, simple, resource file format to XML. It just introduces another level of complexity for no real benefit. > Beyond that, I haven't had an itch to scratch with programming for a > while, so I can't comment too much on Pythoncard's current state. > Although I'll probably be updating my Python install to 2.6 and > checking that my software still works... I recall that when reading > that they planned to break compatibility with past code in Python 2.6 > that it sounded like a really boneheaded idea... hopefully I'll find > that it was only obscure code that was going to become incompatible. > Python 2.6 does not break compatibility with previous versions, Python 3.0 does, however. As far as reports go there shouldn't (touch wood) be any problems running code like PythonCard under Python 2.6 > Mark > Regards, Andy -- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ |
|
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-11-27 09:47:20
|
On Thu, 27 Nov 2008 19:58:27 +1100 Andy Todd <an...@ha...> wrote: > Python 2.6 does not break compatibility with previous versions, > Python 3.0 does, however. As far as reports go there shouldn't (touch > wood) be any problems running code like PythonCard under Python 2.6 Kevin and I had a short conversation on the developer list about this, and from some VERY brief testing it looks like all my non-ctypes-using projects still work fine under Python 2.6 + wxPython 2.8.9.1 (on Windows XP at least). The only thing that seems to have broken is the PythonCard installer, but this looks like the same issue that broke the PythonCard 0.81 installer when Python 2.4 came out. I've added the issue to the bugtracker. -- XXXXXXXXXXX |
|
From: Alex T. <al...@tw...> - 2008-11-26 22:37:02
|
Nextime wrote: > Hello all. > > As a demostration that nothing is moving here, after few posts saying > "i don't agree with a fork", nothing more on this list or in > developement of PythonCard. > > Other than my post on the 13th ? I haven't yet seen any reply to what I said. > So, with all my thanks for all original developers of pythoncard > for the base code of the new project, i have forked pythoncard. > > The new project will be called "Picard", and the developemed will be > completely separated from the one of pythoncard. > > Picard is a name dedicated to the Cpt. Picard from StarTrek TNG, > cause of the assonance ( at least in my language ) with "PyCard". > > actually i have a pre-release on my svn, at > https://svn.nexlab.it/medianix/packages/main/pythoncard/trunk > whit those changed from the original codebase: > > - Patched with changes from Alex Tweedly for sizers > I strongly recommend that these not be used, other than for testing purposes. I'll look at any feedback (on this list), but can't guarantee to respond in a timely manner. I do not stand behind these not-yet-properly-tested changes, and I think it's a bad idea to have them included in the default download. -- Alex Tweedly. |
|
From: Nextime <ne...@ne...> - 2008-11-27 07:40:08
|
On Wed, Nov 26, 2008 at 10:36:54PM +0000, Alex Tweedly wrote: > > Nextime wrote: >> Hello all. >> >> As a demostration that nothing is moving here, after few posts saying >> "i don't agree with a fork", nothing more on this list or in >> developement of PythonCard. >> >> > Other than my post on the 13th ? > I haven't yet seen any reply to what I said. Sorry but i don't see nor in the archive nor in my email any post from you on the 13th. >> - Patched with changes from Alex Tweedly for sizers >> > I strongly recommend that these not be used, other than for testing > purposes. Well, do you know the words "developement version" and "pre-release"? This is not a "stable download released" but a developement one. When those changes are tested enough they will be released as default download, for the moment they are in a developement version. Also, if you don't put the code in a branch or in a developement version, how can anyone test it and give you feedback? > I'll look at any feedback (on this list), but can't guarantee > to respond in a timely manner. You can have feedback if you put your code in Pythoncard, but the codebase of Picard will be different from the Pythoncard soon, so, feedback from Picard will not be the one that you want here. I will look at any feedback and i try to respond in timely manner on the right mailing list for the project *with* the code to be tested. > > I do not stand behind these > not-yet-properly-tested changes, and I think it's a bad idea to have > them included in the default download. It is a svn trunk version... not a default download. Cheers -- Franco Lanza My blog: http://www.nexlab.it email: ne...@ne... Fax/Tel: +39 0331 682151 Cell: +39 339 8125940 Busto Arsizio (VA) - Italy ----------------------------------- Per consulenze telefoniche chiamate: ** 899.161.414 ** Servizio riservato ai maggiorenni, tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta) abilitazione decreto ministero delle comunicazioni n. 145 del 02/03/2006, offerto da Deram Srl in collaborazione con UnixMedia Srl ----------------------------------- NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- |
|
From: Alex T. <al...@tw...> - 2008-11-27 22:50:41
|
Nextime wrote:
> On Wed, Nov 26, 2008 at 10:36:54PM +0000, Alex Tweedly wrote:
>
>> Nextime wrote:
>>
>>> Hello all.
>>>
>>> As a demostration that nothing is moving here, after few posts saying
>>> "i don't agree with a fork", nothing more on this list or in
>>> developement of PythonCard.
>>>
>>>
>>>
>> Other than my post on the 13th ?
>> I haven't yet seen any reply to what I said.
>>
>
>
> Sorry but i don't see nor in the archive nor in my email any post from
> you on the 13th.
>
>
Hmmmm - odd. I know I sent it, and received a copy of it back - no idea
why you don't / didn't see it.
Most of it is probably out of date now, so I'll include just the two
most relevant paragraphs again here :
> What new things do we have ? Which of them are *ready* to go into
> the actual project ?
>
> I know for sure that my sizer code isn't ready to be committed.
> That's why it's on a separate website - it's still 'experimental'. It
> hasn't been tested anywhere near enough to be ready to put it into
> CVS. It's fine for someone who has been actively following discussions
> to try something that may break, or behave strangely, or indeed may
> work but just not be the right approach in the long run; but it would
> be very wrong to put such experiments into the repository where anyone
> trying out Pythoncard for the first time is exposed to those dangers.
>>> - Patched with changes from Alex Tweedly for sizers
>>>
>>>
>> I strongly recommend that these not be used, other than for testing
>> purposes.
>>
>
> Well, do you know the words "developement version" and "pre-release"?
>
>
Yes, thanks. I have spent a few years managing software development
groups of 150+ engineers - I'm far too familiar wth both those terms
:-) And with the wide variety of meanings people attach to each of them.
> This is not a "stable download released" but a developement one.
> When those changes are tested enough they will be released as default
> download, for the moment they are in a developement version.
>
> Also, if you don't put the code in a branch or in a developement
> version, how can anyone test it and give you feedback?
>
>
How can anyone test it or give feedback ? Easy -
I put it on a website.
I announced it on the pythoncard-users list.
A number of people (including you) managed to find it;
quite a few expressed some interest in it;
but very, very few tested it and provided any feedback.
All the other changes I made to Pythoncard followed the same, or
similar, process:
- put code (or diffs) on a website OR send them directly to fellow
collaborators
- announce to users list
- get feedback, update, .....
- once there has been enough feedback and/or enough bugs fixed, post
diffs to developers list
- incorporate any developer changes / suggestions
- then and only then put into cvs
That worked pretty well, until we got the sizer changes. A good number
of people were interested - but not sufficiently to actually test it
thoroughly. That kind of convinced me that there was actually less need
than I had thought, as confirmed by my own experience.
I found that many times I used Pythoncard for a quick, simple GUI for my
own use without needing sizers (and if I wanted to use it
cross-platform, then I'd just adjust things). If I did want to release
the program to other people, I'd do so after some time - so the basic
layout, controls, components, etc. were fairly settled - and in that
case, it wasn't a big deal to put the sizers in as code (as is done,
e.g., in 'findfiles'). And for the early experimentation, I much
referred the static layout of the existing editor to the thought and
effort needed to organize and put components into sizers). So even I
didn't actually use the sizer changes enough :-)
Net result - it just hasn't been tested that much. It's at a very
different stage of readiness than the rest of the code in the Pythoncard
repository.
>> I'll look at any feedback (on this list), but can't guarantee
>> to respond in a timely manner.
>>
>
> You can have feedback if you put your code in Pythoncard, but the
> codebase of Picard will be different from the Pythoncard soon, so,
> feedback from Picard will not be the one that you want here.
>
>
I can have feedback from anyone who wants to download it from
tweedly.net and test it - it's been there for almost 3 years now,
without gathering much feedback. (Anyone who wants the URL, or docs,
etc. can contact me off-list.)
> I will look at any feedback and i try to respond in timely manner on the
> right mailing list for the project *with* the code to be tested.
>
>
>> I do not stand behind these
>> not-yet-properly-tested changes, and I think it's a bad idea to have
>> them included in the default download.
>>
>
> It is a svn trunk version... not a default download.
>
>
The way I read your email, these changes were (or were going to be)
included in the svn trunk - so no-one can dowload Picard without getting
these changes included. If that's not the case, and people can get the
reliable version of the layoutEditor or *choose* to get this version,
then that's fine. But if these changes come included by downloading
Picard, then I think it would be worth a specific warning about this
part of the code (though you could argue this email thread should be
enough of a disclaimer).
Good luck
-- Alex.
|
|
From: Nextime <ne...@ne...> - 2008-11-28 00:00:06
|
On Thu, Nov 27, 2008 at 10:50:30PM +0000, Alex Tweedly wrote: > All the other changes I made to Pythoncard followed the same, or > similar, process: > - put code (or diffs) on a website OR send them directly to fellow > collaborators > - announce to users list > - get feedback, update, ..... > - once there has been enough feedback and/or enough bugs fixed, post > diffs to developers list > - incorporate any developer changes / suggestions > - then and only then put into cvs I don't agree with this method. In my opinion, any changes or patch shuld be committed on an experimental branch (or even in trunk/HEAD for little projects ), only this way people interested in the developement version can test it and provide feedback in an actively manner. When and if the changes will be considered stable enough, they will be included in the release branch, or tag, or stable, or what you want to call it. This is how most of the projects go ahead, and i think is the only way to let developers that know what they do find, test, and patch or reply with feedback. > That worked pretty well, until we got the sizer changes. A good number > of people were interested - but not sufficiently to actually test it > thoroughly. That kind of convinced me that there was actually less need > than I had thought, as confirmed by my own experience. I don't agree. It don't work pretty well if we have about 1 commit a year. Also, this isn't the only one issue. Also there is the problem of the devel ml not responsive, and i don't want to see an answer to every message in few minutes/hours, but i want an answer at least in 1/2 weeks where i ask about the status of the project. Exceptions permitted, of course, but Jesus, this is the usual way on pythoncard, not an exception. > I found that many times I used Pythoncard for a quick, simple GUI for my > own use without needing sizers (and if I wanted to use it > cross-platform, then I'd just adjust things). I agree in this. Me too. But this isn't a reason to let the project stalled for *TWO YEARS*! > The way I read your email, these changes were (or were going to be) > included in the svn trunk - so no-one can dowload Picard without getting > these changes included. Yes, no one can download it without those changes included. Exactly, no one can download the new *developement* branch without those changes included. When and only when i will release something that i will call "stable" you can argue with those things. > If that's not the case, and people can get the > reliable version of the layoutEditor or *choose* to get this version, > then that's fine. But if these changes come included by downloading > Picard, then I think it would be worth a specific warning about this > part of the code (though you could argue this email thread should be > enough of a disclaimer). People that download a trunk developement branch from an svn usually know what they do. People that don't know what to do, usually don't know how to use an svn repository nor how to install something that isn't an exe or msi installer. Anyway, after all, i've done my choice. I now have a fork with the things i want to have, i will have a new project that will evolve more quickly, probably in different direction of pythoncard. Anyone is free to follow me or to stay here... to wait something moving. > Good luck Thanks. -- Franco Lanza My blog: http://www.nexlab.it email: ne...@ne... Fax/Tel: +39 0331 682151 Cell: +39 339 8125940 Busto Arsizio (VA) - Italy ----------------------------------- Per consulenze telefoniche chiamate: ** 899.161.414 ** Servizio riservato ai maggiorenni, tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta) abilitazione decreto ministero delle comunicazioni n. 145 del 02/03/2006, offerto da Deram Srl in collaborazione con UnixMedia Srl ----------------------------------- NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- |
|
From: phil j. <int...@gm...> - 2008-11-28 00:26:21
|
I think it's always a bit ugly to have a "hostile" forking. But my sympathies are with Nextime here. Managing the difference between work-in-progress vs. stable releases *is* a problem that has been reasonably solved by the branching / tagging mechanisms of source-control systems. There doesn't seem a strong reason to have to manually juggle patches from different web-sites. That appears unnecessary extra work. I look forward to being able to install bleeding edge PythonCard / Picard in one go; and I hope that pushing the sizers on users may actually focus more attention and testing on them. OTOH, I'd suggest to Nextime that he makes a tag of the pre-sizer release so that those who are concerned can avoid it. phil On Thu, Nov 27, 2008 at 8:59 PM, Nextime <ne...@ne...> wrote: > On Thu, Nov 27, 2008 at 10:50:30PM +0000, Alex Tweedly wrote: >> All the other changes I made to Pythoncard followed the same, or >> similar, process: >> - put code (or diffs) on a website OR send them directly to fellow >> collaborators >> - announce to users list >> - get feedback, update, ..... >> - once there has been enough feedback and/or enough bugs fixed, post >> diffs to developers list >> - incorporate any developer changes / suggestions >> - then and only then put into cvs > > I don't agree with this method. > > In my opinion, any changes or patch shuld be committed on an > experimental branch (or even in trunk/HEAD for little projects ), > only this way people interested in the developement > version can test it and provide feedback in an actively manner. > > When and if the changes will be considered stable enough, they will be > included in the release branch, or tag, or stable, or what you want to call it. > > This is how most of the projects go ahead, and i think is the only way > to let developers that know what they do find, test, and patch or reply > with feedback. > >> That worked pretty well, until we got the sizer changes. A good number >> of people were interested - but not sufficiently to actually test it >> thoroughly. That kind of convinced me that there was actually less need >> than I had thought, as confirmed by my own experience. > > I don't agree. It don't work pretty well if we have about 1 commit a > year. > > Also, this isn't the only one issue. Also there is the problem of the > devel ml not responsive, and i don't want to see an answer to every > message in few minutes/hours, but i want an answer at least in 1/2 weeks > where i ask about the status of the project. Exceptions permitted, of > course, but Jesus, this is the usual way on pythoncard, not an > exception. > >> I found that many times I used Pythoncard for a quick, simple GUI for my >> own use without needing sizers (and if I wanted to use it >> cross-platform, then I'd just adjust things). > > I agree in this. Me too. But this isn't a reason to let the project > stalled for *TWO YEARS*! > >> The way I read your email, these changes were (or were going to be) >> included in the svn trunk - so no-one can dowload Picard without getting >> these changes included. > > Yes, no one can download it without those changes included. Exactly, no > one can download the new *developement* branch without those changes > included. When and only when i will release something that i will call > "stable" you can argue with those things. > >> If that's not the case, and people can get the >> reliable version of the layoutEditor or *choose* to get this version, >> then that's fine. But if these changes come included by downloading >> Picard, then I think it would be worth a specific warning about this >> part of the code (though you could argue this email thread should be >> enough of a disclaimer). > > > People that download a trunk developement branch from an svn usually > know what they do. People that don't know what to do, usually don't know > how to use an svn repository nor how to install something that isn't an > exe or msi installer. > > Anyway, after all, i've done my choice. I now have a fork with the > things i want to have, i will have a new project that will evolve more > quickly, probably in different direction of pythoncard. Anyone is free > to follow me or to stay here... to wait something moving. > > >> Good luck > > Thanks. > > > -- > > Franco Lanza > My blog: http://www.nexlab.it > email: ne...@ne... > Fax/Tel: +39 0331 682151 > Cell: +39 339 8125940 > Busto Arsizio (VA) - Italy > ----------------------------------- > Per consulenze telefoniche chiamate: > ** 899.161.414 ** > Servizio riservato ai maggiorenni, > tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta) > abilitazione decreto ministero delle comunicazioni > n. 145 del 02/03/2006, offerto da Deram Srl in > collaborazione con UnixMedia Srl > ----------------------------------- > NO TCPA: http://www.no1984.org > you can download my public key at: > http://danex.nexlab.it/nextime.asc || Key Servers > Key ID = D6132D50 > Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 > ----------------------------------- > echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc > ----------------------------------- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkkvNHsACgkQ3+31gNYTLVB4dQCg0CnAHefQFnxJ97wwZ3EIFgtr > tK0AoIzHk+LKo4Ngo/P0Dj3we4jShb8X > =wedb > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X