[ANN] Source control versioning system migration to GIT
Locked
 
|
Dado Sutter |
[ANN] Source control versioning system migration to GIT
|
Hello List,
The eLua project will change its source control versioning system from Subversion to GIT (http://git-scm.com/). The master repository host will also move from BerliOS to github at https://github.com/elua/elua. This change will become effective on March 1st 2011, three weeks from now. After this date the eLua subversion repository will no longer be accessible. If you are unfamiliar with git, here is a couple of links to get you started:
Bogdan Marinescu Dado Sutter James Snyder _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: [ANN] Source control versioning system migration to GIT
|
|
On 9 February 2011 15:23, Dado Sutter <[hidden email]> wrote:
> The master repository host will also move from BerliOS to github at > https://github.com/elua/elua. > This change will become effective on March 1st 2011, three weeks from > now. After this date the eLua > subversion repository will no longer be accessible. Hi Can you keep the svn repository read-only for a year or more? Often we have to check bugs against older versions and to deal with old patches and patch sets that were prepared against specific svn versions. Thanks M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> Hi
> Can you keep the svn repository read-only for a year or more? Often > we have to check bugs against older versions and to deal with old > patches and patch sets that were prepared against specific svn > versions. Definitely. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Kevin Vermeer |
Re: [ANN] Source control versioning system migration to GIT
|
|
In reply to this post by Martin Guy
On Wed, Feb 9, 2011 at 9:35 AM, Martin Guy <[hidden email]> wrote: I was going to request an svnadmin dump of the repository:
http://svnbook.red-bean.com/en/1.5/svn.ref.svnadmin.c.dump.html ..but a read-only version sounds like a better idea. With a dump, you might get users who are more comfortable with svn downloading the dump and continuing development locally. I guess I'll finally have to buckle down and learn git. -- Kevin Vermeer _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick-11 |
Re: [ANN] Source control versioning system migration to GIT
|
|
In reply to this post by Dado Sutter
James hinted at this in the Floss weekly interview.....
It all sounds good-Pat _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Kevin Vermeer
> I was going to request an svnadmin dump of the repository:
> http://svnbook.red-bean.com/en/1.5/svn.ref.svnadmin.c.dump.html > ..but a read-only version sounds like a better idea. With a dump, you might > get users who are more comfortable with svn downloading the dump and > continuing development locally. > > I guess I'll finally have to buckle down and learn git. I was quite hesitant about git at first but now I'm fully ready to embrace it, especially after svn performed very poorly in some relatively simple merging scenarios. I recommend the git community book (http://book.git-scm.com/index.html) as a good starter on the topic. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
Actually, github also has a mechanism for checking out from live git
repositories using SVN: https://github.com/blog/626-announcing-svn-support (although there appears to be a problem with that at the moment) There are plans, however, as Bogdan mentioned to maintain a mirror. I'm not yet sure that it would be one that could be seamlessly used with an existing checkout, but I'll see what can be done on that front, and whatever solution is used there will be part of the announcement. I'll most likely use something like this: http://repo.or.cz/w/git2svn.git That said, I think for those out there mainly tracking the repository and not making modifications you should find it fairly easy to do with git. We'll provide some examples of how to do this. For now, as in the announcement above, if you'd like a general guide to using git for SVN users, check out: http://git.or.cz/course/svn.html If there are specific questions or problems that you end up experiencing, don't hesitate to let us know on the list. On Wed, Feb 9, 2011 at 8:35 AM, Martin Guy <[hidden email]> wrote: > On 9 February 2011 15:23, Dado Sutter <[hidden email]> wrote: >> The master repository host will also move from BerliOS to github at >> https://github.com/elua/elua. >> This change will become effective on March 1st 2011, three weeks from >> now. After this date the eLua >> subversion repository will no longer be accessible. > > Hi > Can you keep the svn repository read-only for a year or more? Often > we have to check bugs against older versions and to deal with old > patches and patch sets that were prepared against specific svn > versions. > > Thanks > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> There are plans, however, as Bogdan mentioned to maintain a mirror.
Thanks, James. Just to clarify: I was not suggesting a mirror, rather a "freeze" of the SVN repository at the precise moment or March 1st, after which it will only be accesible in R/O mode. I personally don't see the benefits of a mirror after we switch to git but please let us know if you think differently. Best, Bogdan > On Wed, Feb 9, 2011 at 8:35 AM, Martin Guy <[hidden email]> wrote: >> On 9 February 2011 15:23, Dado Sutter <[hidden email]> wrote: >>> The master repository host will also move from BerliOS to github at >>> https://github.com/elua/elua. >>> This change will become effective on March 1st 2011, three weeks from >>> now. After this date the eLua >>> subversion repository will no longer be accessible. >> >> Hi >> Can you keep the svn repository read-only for a year or more? Often >> we have to check bugs against older versions and to deal with old >> patches and patch sets that were prepared against specific svn >> versions. >> >> Thanks >> >> M >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Feb 9, 2011 at 12:53 PM, Bogdan Marinescu
<[hidden email]> wrote: >> There are plans, however, as Bogdan mentioned to maintain a mirror. > > Thanks, James. Just to clarify: I was not suggesting a mirror, rather > a "freeze" of the SVN repository at the precise moment or March 1st, > after which it will only be accesible in R/O mode. I personally don't > see the benefits of a mirror after we switch to git but please let us > know if you think differently. I suppose I misunderstood a little bit. I figured what was on berlios would certainly stop, what I was thinking of was having a mirror at another URL. I suppose that question could be left open to others on the list: does anyone need/want an SVN mirror? It wouldn't take too much effort to set up, but I would recommend everyone working with newer revisions pull them from git rather than SVN. Also note: our Git repo will _not_ drop any of the eLua revision history. It keeps all of our history. However, it does not include the SVN revision numbers... Another thing we could probably do is generate a table of corresponding git and svn revs for commits prior to the changeover, but I'm not sure how much utility people might find in that. > > Best, > Bogdan > >> On Wed, Feb 9, 2011 at 8:35 AM, Martin Guy <[hidden email]> wrote: >>> On 9 February 2011 15:23, Dado Sutter <[hidden email]> wrote: >>>> The master repository host will also move from BerliOS to github at >>>> https://github.com/elua/elua. >>>> This change will become effective on March 1st 2011, three weeks from >>>> now. After this date the eLua >>>> subversion repository will no longer be accessible. >>> >>> Hi >>> Can you keep the svn repository read-only for a year or more? Often >>> we have to check bugs against older versions and to deal with old >>> patches and patch sets that were prepared against specific svn >>> versions. >>> >>> Thanks >>> >>> M >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> [hidden email] >> PGP: http://fanplastic.org/key.txt >> Phone: (847) 448-0386 >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> I suppose I misunderstood a little bit. I figured what was on berlios
> would certainly stop, what I was thinking of was having a mirror at > another URL. Ah OK, my bad. We were talking about different things. > I suppose that question could be left open to others on > the list: does anyone need/want an SVN mirror? It wouldn't take too > much effort to set up, but I would recommend everyone working with > newer revisions pull them from git rather than SVN. > > Also note: our Git repo will _not_ drop any of the eLua revision > history. It keeps all of our history. However, it does not include > the SVN revision numbers... ... which is exactly why someone would need the old repository in read-only mode for a while. Not a git mirror, mind you, just the old repo. Best, Bogdan >>> On Wed, Feb 9, 2011 at 8:35 AM, Martin Guy <[hidden email]> wrote: >>>> On 9 February 2011 15:23, Dado Sutter <[hidden email]> wrote: >>>>> The master repository host will also move from BerliOS to github at >>>>> https://github.com/elua/elua. >>>>> This change will become effective on March 1st 2011, three weeks from >>>>> now. After this date the eLua >>>>> subversion repository will no longer be accessible. >>>> >>>> Hi >>>> Can you keep the svn repository read-only for a year or more? Often >>>> we have to check bugs against older versions and to deal with old >>>> patches and patch sets that were prepared against specific svn >>>> versions. >>>> >>>> Thanks >>>> >>>> M >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>> >>> >>> >>> -- >>> James Snyder >>> Biomedical Engineering >>> Northwestern University >>> [hidden email] >>> PGP: http://fanplastic.org/key.txt >>> Phone: (847) 448-0386 >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: [ANN] Source control versioning system migration to GIT
|
|
On 9 February 2011 22:47, Bogdan Marinescu <[hidden email]> wrote:
>> Also note: our Git repo will _not_ drop any of the eLua revision >> history. It keeps all of our history. However, it does not include >> the SVN revision numbers... > > ... which is exactly why someone would need the old repository in > read-only mode for a while. Not a git mirror, mind you, just the old > repo. Just freezing the existing svn repo at the same URL seems best to me so that existing shell scripts, instructions in documentation, version-specific patch sets and so on continue to work exactly as they are. What's it called. "backward compatability"? No. "Continuity"? Probably not that either. I'm sure there must be some technical term for the principle of not breaking other people's existing work by remote control by changing things, unless it is absolutely unavoidable to achieve some effect. Think how much you love those web sites that you linked to in your web sites, which then change structure so that all your links get broken without you knowing it. Then extend that idea for avoiding breakage to open-source software repositories. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ronan Paixão-2 |
Re: [ANN] Source control versioning system migration to GIT
|
|
Possibly the term is "legacy support"
2011/2/10 Martin Guy <[hidden email]>
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: [ANN] Source control versioning system migration to GIT
|
|
Hello,
2011/2/13 Ronan Paixão <[hidden email]> Possibly the term is "legacy support" We don't know what people that don't share results here on the list are doing with eLua, although we do know that there are some. I think that until we have something that we will be able to (and be proud of) call eLua v1.0, changes that can break some legacy behavior are possible. We can be more careful even before that, when we hear actual reasons to do some extra work to support it and this is what we're hearing now. It is nice to know people are using eLua and we'll do our best to support any use of what we're creating. I also want to publish on the site or here on the list, something I should have done a long time ago, which is an "eLua Roadmap" to make clear the directions we're going and to make possible people to contribute for it. It will come with the new site (hopefully 3~5 weeks from now) or even before that on the wiki. We will also have to find a way to make available the old links to the (current) doc, that people may have bookmarked. In one way or another, they will be linked to the main site. Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
I'm new to the list and new to Lua so I don't
have any fantastic application but I'll tell you what I'm planning to try with eLua. I have several compatible boards on their way for two separate projects, the ET-SMT32 from Futurlec, they are pretty reasonable at $25. < <http://www.futurlec.com/ET-STM32_Stamp.shtml>http://www.futurlec.com/ET-STM32_Stamp.shtml > Project #1 a PID controller for an oven to solder SMT boards, this will control an ovens heater element to ramp up and down the temperature in an oven in a controlled way so that a PCB board is soldered properly while avoiding damaging the components. It will interface to a 20 key pad, a graphic display, a A/D port reading a K thermocouple amplifier, sound alarms, and an optically isolated Solid state relay to control the heater elements. I will graphically show the temperature live and be able to store calibrating data as to what the behavior of the heater is like so it will not overshoot is temperature. I don't have too many doubts that this will work since the control loop does not need to be very fast dues to the slow nature of the process. Project #2 is the control element of a homemade radio transceiver. This will use a PC keyboard, mouse, Graphic display, and USB port and RS232 Port to communicate with a PC or a DSP processor. The controller will provide control of filters, timing control as the radios switches between receive and transmit functions. Project #2 is more questionable since I have not actually tried eLua so I don't know how fast it is, also for this to work I need access to i2c hardware and possible USB ports which support are not yet available for the ARM controller that I will use. Since these are new projects and I don't have Lua experience compatibility is not an issue for me, although it would be nice to not deviate from the PC versions of Lua. I'm looking forward to this experiment and I'm hoping it all works out as an interactive system is a great help in working out the problems. Thanks for providing the software. At 09:44 AM 2/13/2011, you wrote: >Hello, > >2011/2/13 Ronan Paixão <<mailto:[hidden email]>[hidden email]> >Possibly the term is "legacy support" > > > We don't know what people that don't share > results here on the list are doing with eLua, > although we do know that there are some. > I think that until we have something that we > will be able to (and be proud of) call eLua > v1.0, changes that can break some legacy > behavior are possible. We can be more careful > even before that, when we hear actual reasons > to do some extra work to support it and this is what we're hearing now. > It is nice to know people are using eLua and > we'll do our best to support any use of what we're creating. > I also want to publish on the site or here > on the list, something I should have done a > long time ago, which is an "eLua Roadmap" to > make clear the directions we're going and to > make possible people to contribute for it. It > will come with the new site (hopefully 3~5 > weeks from now) or even before that on the wiki. > We will also have to find a way to make > available the old links to the (current) doc, > that people may have bookmarked. In one way or > another, they will be linked to the main site. > >Best >Dado Cecil k5nwa < www.softrockradio.org > < www.qrpradio.com > < http://parts.softrockradio.org/ > Never take life seriously. Nobody gets out alive anyway. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: [ANN] Source control versioning system migration to GIT
|
|
Hello,
On Sun, Feb 13, 2011 at 14:54, cbayona <[hidden email]> wrote: I'm new to the list and new to Lua so I don't have any fantastic application but I'll tell you what I'm planning to try with eLua. And the instructions on how to use them with eLua are at http://www.eluaproject.net/en_installing_stm32.html Project #1 a PID controller for an oven to solder SMT boards, this will control an ovens heater element to ramp up and down the temperature in an oven in a controlled way so that a PCB board is soldered properly while avoiding damaging the components. Very nice It will interface to a 20 key pad There's a nice $3.95 model from Sparkfun at http://www.sparkfun.com/products/8653 (of course there's always cheaper options elsewhere). , a graphic display, We have a couple of drivers working already and would love to have more, including touch screen support, quickly appearing on some units now. a A/D port reading a K thermocouple amplifier, sound alarms, and an optically isolated Solid state relay to control the heater elements. I will graphically show the temperature live and be able to store calibrating data as to what the behavior of the heater is like so it will not overshoot is temperature. I don't have too many doubts that this will work since the control loop does not need to be very fast dues to the slow nature of the process. Sounds like a very well fitted project for eLua Project #2 is the control element of a homemade radio transceiver. This will use a PC keyboard for which Thiago Naves wrote a nice C driver for eLua already. It is documented on our wiki at http://wiki.eluaproject.net/eLuaPCKBD , mouse, Graphic display, and USB port and RS232 Port to communicate with a PC or a DSP processor. The controller will provide control of filters, timing control as the radios switches between receive and transmit functions. Lua code in eLua, for obvious reasons, will never be as fast as C code. But we want to make it easy (easier than what it is today) for users like yourself, to code in C where you need more performance and easily integrate this into your application, be it as a loadable C binary module (a roadmap feature) or as a driver statically linked to the eLua image built for your platform (already available but still a bit hard to use. We're currently working on making it easier). also for this to work I need access to i2c hardware and possible USB ports which support are not yet available for the ARM controller that I will use. You can try to go with UARTS and FTDI for USB, if you don't need a true USB host/slave architecture. You can mention the modules you need that are not yet supported on our Wish List (http://wiki.eluaproject.net/Wish%20List). I2C libs are available for most platforms and it is just a matter of extending the support for it. Since these are new projects and I don't have Lua experience compatibility is not an issue for me, although it would be nice to not deviate from the PC versions of Lua. We strive to be full Lua and we actually think that this is one of the main characteristics of eLua. Most of the embedding high-level languages initiatives end up with a sub-sub-sub-set of the language and we don't want this from the start. There are will always be some modules where differences will be found (ie: the "os" module, once we don't have an OS below but still, we'll have it linked to our file-systems in the future) but the main functionality is completely implemented, including some embedded-oriented extensions (like romable tables and functions, emergency garbage collection, ...). I'm looking forward to this experiment and I'm hoping it all works out as an interactive system is a great help in working out the problems. Thank you very much for using and for supporting eLua. Please don't forget to add your credentials to our Who is Using eLua growing list at ttp://wiki.eluaproject.net/Who%20is%20using Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thanks for the feedback, I appreciate the links.
I have Rowley's C compiler for the ARM chips, I'm hoping that it would work as a compiler to build the system, they have all sorts of libraries to allow use of the various ARM hardware devices. The keyboard needs to be 16 keys minimum, 12 keys makes the programming too convoluted, I have a dozen 16 key keypads I bought for less than $1 each but by the time I received them and saw they were really nice quality it was too late to get more but I'm keeping my eyes open for some. I'm hoping the interactive nature of eLua will be a big help in developing and troubleshooting the software. At 12:40 PM 2/14/2011, you wrote: >Hello, > > >On Sun, Feb 13, 2011 at 14:54, cbayona ><<mailto:[hidden email]>[hidden email]> wrote: >I'm new to the list and new to Lua so I don't have any fantastic >application but I'll tell you what I'm planning to try with eLua. > >I have several compatible boards on their way for two separate >projects, the ET-SMT32 from Futurlec, they are pretty reasonable at $25. >< ><<http://www.futurlec.com/ET-STM32_Stamp.shtml>http://www.futurlec.com/ET-STM32_Stamp.shtml>http://www.futurlec.com/ET-STM32_Stamp.shtml > > > > >And the instructions on how to use them with eLua are at ><http://www.eluaproject.net/en_installing_stm32.html>http://www.eluaproject.net/en_installing_stm32.html > > >Project #1 a PID controller for an oven to solder SMT boards, this >will control an ovens heater element to ramp up and down the >temperature in an oven in a controlled way so that a PCB board is >soldered properly while avoiding damaging the components. > > >Very nice > >It will interface to a 20 key pad > > >There's a nice $3.95 model from Sparkfun at ><http://www.sparkfun.com/products/8653>http://www.sparkfun.com/products/8653 >(of course there's always cheaper options elsewhere). > >, a graphic display, > > >We have a couple of drivers working already and would love to have >more, including touch screen support, quickly appearing on some units now. > >a A/D port reading a K thermocouple amplifier, sound alarms, and an >optically isolated Solid state relay to control the heater elements. >I will graphically show the temperature live and be able to store >calibrating data as to what the behavior of the heater is like so it >will not overshoot is temperature. I don't have too many doubts that >this will work since the control loop does not need to be very fast >dues to the slow nature of the process. > > >Sounds like a very well fitted project for eLua > > >Project #2 is the control element of a homemade radio transceiver. >This will use a PC keyboard > > >for which Thiago Naves wrote a nice C driver for eLua already. It is >documented on our wiki at ><http://wiki.eluaproject.net/eLuaPCKBD>http://wiki.eluaproject.net/eLuaPCKBD > >, mouse, Graphic display, and USB port and RS232 Port to communicate >with a PC or a DSP processor. The controller will provide control >of filters, timing control as the radios switches between receive >and transmit functions. > >Project #2 is more questionable since I have not actually tried eLua >so I don't know how fast it is, > > >Lua code in eLua, for obvious reasons, will never be as fast as C >code. But we want to make it easy (easier than what it is today) for >users like yourself, to code in C where you need more performance >and easily integrate this into your application, be it as a loadable >C binary module (a roadmap feature) or as a driver statically linked >to the eLua image built for your platform (already available but >still a bit hard to use. We're currently working on making it easier). > >also for this to work I need access to i2c hardware and possible USB >ports which support are not yet available for the ARM controller >that I will use. > > >You can try to go with UARTS and FTDI for USB, if you don't need a >true USB host/slave architecture. >You can mention the modules you need that are not yet supported on >our Wish List >(<http://wiki.eluaproject.net/Wish%20List>http://wiki.eluaproject.net/Wish%20List). >I2C libs are available for most platforms and it is just a matter of >extending the support for it. > >Since these are new projects and I don't have Lua experience >compatibility is not an issue for me, although it would be nice to >not deviate from the PC versions of Lua. > > >We strive to be full Lua and we actually think that this is one of >the main characteristics of eLua. Most of the embedding high-level >languages initiatives end up with a sub-sub-sub-set of the language >and we don't want this from the start. There are will always be some >modules where differences will be found (ie: the "os" module, once >we don't have an OS below but still, we'll have it linked to our >file-systems in the future) but the main functionality is completely >implemented, including some embedded-oriented extensions (like >romable tables and functions, emergency garbage collection, ...). > >I'm looking forward to this experiment and I'm hoping it all works >out as an interactive system is a great help in working out the problems. > >Thanks for providing the software. > > >Thank you very much for using and for supporting eLua. > >Please don't forget to add your credentials to our Who is Using eLua >growing list at >ttp://<http://wiki.eluaproject.net/Who%20is%20using>wiki.eluaproject.net/Who%20is%20using > >Best >Dado > >SNIP Cecil K5NWA < www.softrockradio.org > < www.qrpradio.com > < http://parts.softrockradio.org/ > When life gives you lemons, you'd better wait for it to give you some sugar first or else you'll have some really nasty-tasting lemonade. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: [ANN] Source control versioning system migration to GIT
|
|
On Mon, Feb 14, 2011 at 17:55, cbayona <[hidden email]> wrote: Thanks for the feedback, I appreciate the links. The keyboard needs to be 16 keys minimum, 12 keys makes the programming too convoluted, I have a dozen 16 key keypads I bought for less than $1 each but by the time I received them and saw they were really nice quality it was too late to get more but I'm keeping my eyes open for some. Cool, pls share it eventually. I'm hoping the interactive nature of eLua will be a big help in developing and troubleshooting the software. It's been doing great for our (my Lab @PUC-Rio's) internal and commercial projects. Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Please don't hijack the thread. Let's keep this thread focused to moving on git.
Thanks, Bogdan On Tue, Feb 15, 2011 at 1:08 PM, Dado Sutter <[hidden email]> wrote: > > > On Mon, Feb 14, 2011 at 17:55, cbayona <[hidden email]> wrote: >> >> Thanks for the feedback, I appreciate the links. >> >> I have Rowley's C compiler for the ARM chips, I'm hoping that it would >> work as a compiler to build the system, they have all sorts of libraries to >> allow use of the various ARM hardware devices. > > >> >> The keyboard needs to be 16 keys minimum, 12 keys makes the programming >> too convoluted, I have a dozen 16 key keypads I bought for less than $1 each >> but by the time I received them and saw they were really nice quality it was >> too late to get more but I'm keeping my eyes open for some. > > Cool, pls share it eventually. > >> >> I'm hoping the interactive nature of eLua will be a big help in developing >> and troubleshooting the software. > > It's been doing great for our (my Lab @PUC-Rio's) internal and commercial > projects. > > Best > Dado > > > > >> >> >> At 12:40 PM 2/14/2011, you wrote: >>> >>> Hello, >>> >>> >>> On Sun, Feb 13, 2011 at 14:54, cbayona >>> <<mailto:[hidden email]>[hidden email]> wrote: >>> I'm new to the list and new to Lua so I don't have any fantastic >>> application but I'll tell you what I'm planning to try with eLua. >>> >>> I have several compatible boards on their way for two separate projects, >>> the ET-SMT32 from Futurlec, they are pretty reasonable at $25. >>> < >>> <<http://www.futurlec.com/ET-STM32_Stamp.shtml>http://www.futurlec.com/ET-STM32_Stamp.shtml>http://www.futurlec.com/ET-STM32_Stamp.shtml >>> > >>> >>> >>> And the instructions on how to use them with eLua are at >>> <http://www.eluaproject.net/en_installing_stm32.html>http://www.eluaproject.net/en_installing_stm32.html >>> >>> >>> Project #1 a PID controller for an oven to solder SMT boards, this will >>> control an ovens heater element to ramp up and down the temperature in an >>> oven in a controlled way so that a PCB board is soldered properly while >>> avoiding damaging the components. >>> >>> >>> Very nice >>> >>> It will interface to a 20 key pad >>> >>> >>> There's a nice $3.95 model from Sparkfun at >>> <http://www.sparkfun.com/products/8653>http://www.sparkfun.com/products/8653 >>> (of course there's always cheaper options elsewhere). >>> >>> , a graphic display, >>> >>> >>> We have a couple of drivers working already and would love to have more, >>> including touch screen support, quickly appearing on some units now. >>> >>> a A/D port reading a K thermocouple amplifier, sound alarms, and an >>> optically isolated Solid state relay to control the heater elements. I will >>> graphically show the temperature live and be able to store calibrating data >>> as to what the behavior of the heater is like so it will not overshoot is >>> temperature. I don't have too many doubts that this will work since the >>> control loop does not need to be very fast dues to the slow nature of the >>> process. >>> >>> >>> Sounds like a very well fitted project for eLua >>> >>> >>> Project #2 is the control element of a homemade radio transceiver. This >>> will use a PC keyboard >>> >>> >>> for which Thiago Naves wrote a nice C driver for eLua already. It is >>> documented on our wiki at >>> <http://wiki.eluaproject.net/eLuaPCKBD>http://wiki.eluaproject.net/eLuaPCKBD >>> >>> , mouse, Graphic display, and USB port and RS232 Port to communicate with >>> a PC or a DSP processor. The controller will provide control of filters, >>> timing control as the radios switches between receive and transmit >>> functions. >>> >>> Project #2 is more questionable since I have not actually tried eLua so I >>> don't know how fast it is, >>> >>> >>> Lua code in eLua, for obvious reasons, will never be as fast as C code. >>> But we want to make it easy (easier than what it is today) for users like >>> yourself, to code in C where you need more performance and easily integrate >>> this into your application, be it as a loadable C binary module (a roadmap >>> feature) or as a driver statically linked to the eLua image built for your >>> platform (already available but still a bit hard to use. We're currently >>> working on making it easier). >>> >>> also for this to work I need access to i2c hardware and possible USB >>> ports which support are not yet available for the ARM controller that I will >>> use. >>> >>> >>> You can try to go with UARTS and FTDI for USB, if you don't need a true >>> USB host/slave architecture. >>> You can mention the modules you need that are not yet supported on our >>> Wish List >>> (<http://wiki.eluaproject.net/Wish%20List>http://wiki.eluaproject.net/Wish%20List). >>> I2C libs are available for most platforms and it is just a matter of >>> extending the support for it. >>> >>> Since these are new projects and I don't have Lua experience >>> compatibility is not an issue for me, although it would be nice to not >>> deviate from the PC versions of Lua. >>> >>> >>> We strive to be full Lua and we actually think that this is one of the >>> main characteristics of eLua. Most of the embedding high-level languages >>> initiatives end up with a sub-sub-sub-set of the language and we don't want >>> this from the start. There are will always be some modules where differences >>> will be found (ie: the "os" module, once we don't have an OS below but >>> still, we'll have it linked to our file-systems in the future) but the main >>> functionality is completely implemented, including some embedded-oriented >>> extensions (like romable tables and functions, emergency garbage collection, >>> ...). >>> >>> I'm looking forward to this experiment and I'm hoping it all works out as >>> an interactive system is a great help in working out the problems. >>> >>> Thanks for providing the software. >>> >>> >>> Thank you very much for using and for supporting eLua. >>> >>> Please don't forget to add your credentials to our Who is Using eLua >>> growing list at >>> ttp://<http://wiki.eluaproject.net/Who%20is%20using>wiki.eluaproject.net/Who%20is%20using >>> >>> Best >>> Dado >>> >>> SNIP >> >> Cecil >> K5NWA >> < www.softrockradio.org > < www.qrpradio.com > >> < http://parts.softrockradio.org/ > >> >> When life gives you lemons, you'd better wait for it to give you some >> sugar first or else you'll have some really nasty-tasting lemonade. >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: [ANN] Source control versioning system migration to GIT
|
|
On 15 February 2011 13:58, Bogdan Marinescu <[hidden email]> wrote:
> Please don't hijack the thread. Let's keep this thread focused to moving on git. +1 For a new subject it's best to start a new thread by composing a new message, not replying to something on a different subject Thanks M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |