Re: [Emc-developers] releases branching (was: Re: axis.N.home-state)
On 24 May 2013 16:43, Sebastian Kuzminsky s...@highlab.com wrote: One thing i'd like to do at the hackfest is talk about what features people want in 2.6, One thing that I am finding really handy is the ability to read HAL and INI from G-code. If you set the correct feature mask then you can use G1 X#_hal[pyvcp.random-control] for example. I don't actually know what the logic is behind making this feature maskable, what is the hidden disadvantage of it? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] releases branching (was: Re: axis.N.home-state)
On 31 May 2013 11:30, Michael Haberler mai...@mah.priv.at wrote: G1 X#_hal[pyvcp.random-control] for example. I don't actually know what the logic is behind making this feature maskable, what is the hidden disadvantage of it? This is executed at readahead time, so was usable only for very limited scenarios; and it is not motion-synced like the M6x operations OK. That seems like something that should be documented, rather than disabled to me. It is clearly no good for live config changes, luckily that isn't what I am using it for. as a start, use this: http://preview.tinyurl.com/mjpmuoz and execute it before accessing the hal pin I will try to remember to have a fiddle with it. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] releases branching (was: Re: axis.N.home-state)
On 24 May 2013 16:43, Sebastian Kuzminsky s...@highlab.com wrote: 2.5.0 is over a year old now, and we're nowhere near releasing 2.6. One thing i'd like to do at the hackfest is talk about what features people want in 2.6, and come up with some sort of plan for getting those features in and stabilizing the 2.6 branch. I assume that this is in addition to things already present in master? I guess it is safe to assume that we will stay with Ubuntu and that this release will target the 12.04 release? I would think that the main candidate New Feature is probably the Xenomai / RT_PREEMPT stuff. Is there any scope for finally main-branching joints_axes3? It appears to offer some really rather useful extra features. Distributing configs for RPi and BeagleBone is also an interesting option that could be considered. (With the caveat that RPi is unlikely ever to be particularly useful) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] releases branching (was: Re: axis.N.home-state)
On May 24, 2013, at 09:53 , andy pugh wrote: On 24 May 2013 16:43, Sebastian Kuzminsky s...@highlab.com wrote: 2.5.0 is over a year old now, and we're nowhere near releasing 2.6. One thing i'd like to do at the hackfest is talk about what features people want in 2.6, and come up with some sort of plan for getting those features in and stabilizing the 2.6 branch. I assume that this is in addition to things already present in master? That's what i had assumed, but last time i talked with mah about it he said he wanted the new-rtos stuff on top of 2.5. As you might guess, i don't want to put the new-rtos code into the stable 2.5 branch. I talked with Chris about it and he pointed out the possibility of branching 2.6 off 2.5 instead of off of master, then putting the new-rtos stuff into that 2.6 branch. We keep 2.5 risk-free (this makes me and the 2.5 RM happy), we get a branch that has the proven stability of 2.5 plus the new-rtos feature (i think this makes mah happy), and we leave the other master features for 2.7, later. If we *were* to branch 2.6 off master, then yes you're right, all the stuff in master would become part of the 2.6 branch. I guess it is safe to assume that we will stay with Ubuntu and that this release will target the 12.04 release? I've certainly been assuming that we'll stay with Ubuntu, and that we'll target basically what we're currently building on the buildbot: Hardy sim rtai, Lucid sim rtai, Precise sim, plus any new rtos options we merge. I hope we merge the new-rtos branches somehow for 2.6, but i think it's largely up to mah and i don't know what his plans/desires are for this. I would think that the main candidate New Feature is probably the Xenomai / RT_PREEMPT stuff. I agree. There are a bunch of minor janitor-level tasks I hope to get into 2.6: * libmodbus3 (i'm currently working on this) * automatic asciidoc math rendering * add support for the hm2 encoder filters * probably other stuff i'm not remembering right now Is there any scope for finally main-branching joints_axes3? It appears to offer some really rather useful extra features. It does seem like a really good branch, and i do want it in mainline at some point. I'm not sure if now's the time to merge it, or after 2.6. Since it's not currently in mainline it doesn't get very widespread testing, and that makes me not trust it and makes me want to give it a long time to stabilize (in mainline, after merging it) before we release it. So if we merge ja3 now, i think it will push out 2.6 even further. Distributing configs for RPi and BeagleBone is also an interesting option that could be considered. (With the caveat that RPi is unlikely ever to be particularly useful) I agree. I looked a bit at building the new-rtos branches for Raspian in an ARM QEMU instance, and i think that might work well for us. This is something i'd love to talk about after the new-rtos branch is merged. -- Sebastian Kuzminsky -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
