From: Alan G. <ag...@sp...> - 2009-10-09 20:45:30
|
Google has some truly horrifying results for ktechlab these days, especially considering all the bugs I introduced into the code recently. =0 www.itschool.gov.in/Website_k_tech/.../K-Tech_Module_Eng.pdf EEK!!! I took another stab at fixing diode today, no luck. =( The nodes and connectors code is firming up nicely, I added many inline comments. The biggest open issue is the code which governs the placement of junctions... The current code causes many *interesting* side effects. =\ Speaking of currents, I think the connector code is good enough to start taking a more serious look at resolving the issues with the calculation of currents. I would suggest a procedure of disabling most of the code except code which transfers information directly from the engine. So for currents you would either get a correct value or "unknown". From there, it shouldn't be that unreasonable to design algorithms which correctly resolve unknown values from known values and fill in at least 90% of the values that are currently wrong. =( Given that people actually use this crap, I think we have a responsibility to try to stabilize what we have right now and focus on regressions and deliver the best ktechlab ever... On the other hand, it might be possible to solicit funding for further development on the project. Here's a reply I got to a blog post I commented on a few months ago: ######################## For AlonzoTG On July 4th, 2009 LucaT (not verified) says: Hello Alonzo, you say that you are the current main developer of Ktechlab so i hope that you can address some serious issues that IMO are slowing down the adoption of this excellent piece of software that we call ktechlab. Before adding new functionalities i think there are stability problems to be addressed. I use the precompiled RPM of Mandriva 2009 and ktechlab sometimes crashes without warning, i also have some friends who use Gentoo and compile it by themselves who experience the same kind of stability issues. The same stability problems have been observed by other people that i know using different distros and ktechlab's versions. Do you experience them too? Because it is pretty bothering to spend time connecting components together and then lose all your work for a sudden and unexpected crash. This is the main reason that keeps me away from ktechlab. It is a very good simulator and it is a shame that it keeps crashing when you less expect it. It would be great to see it used in schools but until it is not stable enough to be usable i doubt anyone will adopt it. Adding new functions is cool... but if the software keeps crashing no one will really use it. Also... i have noticed that disabling the simulation while building the circuit prevents most crashes... why does ktechlab start with simulation enabled by default? Thank you, Luca ###################################### Jeez! I'm shocked that current animation still kinda works cuz I'd been unaware of that feature, after all this time even! =P -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Drew N. <dre...@ya...> - 2009-10-09 23:25:54
|
>Google has some truly horrifying results for ktechlab these days, > especially considering all the bugs I introduced into the code recently. =0 > > www.itschool.gov.in/Website_k_tech/.../K-Tech_Module_Eng.pdf I think this is the link you meant: http://www.itschool.gov.in/Website_k_tech/Eng/K-Tech_Module_Eng.pdf ________________________________ From: Alan Grimes <ag...@sp...> To: kte...@li... Sent: Friday, 9 October, 2009 21:43:33 Subject: [Ktechlab-devel] I googled recent pages with ktechlab Google has some truly horrifying results for ktechlab these days, especially considering all the bugs I introduced into the code recently. =0 www.itschool.gov.in/Website_k_tech/.../K-Tech_Module_Eng.pdf EEK!!! I took another stab at fixing diode today, no luck. =( The nodes and connectors code is firming up nicely, I added many inline comments. The biggest open issue is the code which governs the placement of junctions... The current code causes many *interesting* side effects. =\ Speaking of currents, I think the connector code is good enough to start taking a more serious look at resolving the issues with the calculation of currents. I would suggest a procedure of disabling most of the code except code which transfers information directly from the engine. So for currents you would either get a correct value or "unknown". From there, it shouldn't be that unreasonable to design algorithms which correctly resolve unknown values from known values and fill in at least 90% of the values that are currently wrong. =( Given that people actually use this crap, I think we have a responsibility to try to stabilize what we have right now and focus on regressions and deliver the best ktechlab ever... On the other hand, it might be possible to solicit funding for further development on the project. Here's a reply I got to a blog post I commented on a few months ago: ######################## For AlonzoTG On July 4th, 2009 LucaT (not verified) says: Hello Alonzo, you say that you are the current main developer of Ktechlab so i hope that you can address some serious issues that IMO are slowing down the adoption of this excellent piece of software that we call ktechlab. Before adding new functionalities i think there are stability problems to be addressed. I use the precompiled RPM of Mandriva 2009 and ktechlab sometimes crashes without warning, i also have some friends who use Gentoo and compile it by themselves who experience the same kind of stability issues. The same stability problems have been observed by other people that i know using different distros and ktechlab's versions. Do you experience them too? Because it is pretty bothering to spend time connecting components together and then lose all your work for a sudden and unexpected crash. This is the main reason that keeps me away from ktechlab. It is a very good simulator and it is a shame that it keeps crashing when you less expect it. It would be great to see it used in schools but until it is not stable enough to be usable i doubt anyone will adopt it. Adding new functions is cool... but if the software keeps crashing no one will really use it. Also... i have noticed that disabling the simulation while building the circuit prevents most crashes... why does ktechlab start with simulation enabled by default? Thank you, Luca ###################################### Jeez! I'm shocked that current animation still kinda works cuz I'd been unaware of that feature, after all this time even! =P -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Ktechlab-devel mailing list Kte...@li... https://lists.sourceforge.net/lists/listinfo/ktechlab-devel |
From: santiago g. <san...@gm...> - 2009-10-10 02:19:35
|
Why not doing a relase from ktl-0.3.7? It works good enought for me, just need to fix the flowcode (changing 1 line in fpnode) and fix some problems in pic simulation (changing 1 line in gpsimprocessor). There is also a bug when closing files directly shown in screen (created in /temp/k.. ) that can be easily fixed (just don't creating a new temp file). For the piccomponent is not very difficult to add a property to choose clock MHz and add a loop in simulator to manage speed. Running the qtimer at 10 ms does the simulation to go at real time for me. I know there are a lot of people that wants to use Ktechlab for educational purposes, but actually they can't find a ktechlab that works properly. |
From: Zoltan P. <zol...@gm...> - 2009-10-10 17:14:10
|
2009/10/10, santiago gonzalez <san...@gm...>: > Why not doing a relase from ktl-0.3.7? Releasing something on sourceforge needs some rights. Currenly nobody active on the list has them, as far as I know. > > It works good enought for me, just need to fix the flowcode (changing 1 line > in fpnode) and fix some problems in pic simulation (changing 1 line in > gpsimprocessor). I know it's a huge shame for me, but there are lots of mails in my todo folder, for which I haven't got time to do. Exactly what to change and where? > There is also a bug when closing files directly shown in screen (created in > /temp/k.. ) that can be easily fixed (just don't creating a new temp file). This is a new one for me. Which mail haven't I read? > > For the piccomponent is not very difficult to add a property to choose clock > MHz and add a loop in simulator to manage speed. > This is tricky. Some odd behaviour might occur if we have 2 loops in the simulator. > Running the qtimer at 10 ms does the simulation to go at real time for me. > Changeing the simulator's "tick" period should be done one day. There are quite a few issues with the simulator, starting from the total lack of documentation about it. > I know there are a lot of people that wants to use Ktechlab for educational > purposes, but actually they can't find a ktechlab that works properly. > For instance me. And after seeing the codebase, I found this project too challenging to not to join it. :)) |
From: santiago g. <san...@gm...> - 2009-10-10 18:42:29
|
2009/10/10 Zoltan Padrah <zol...@gm...> > 2009/10/10, santiago gonzalez <san...@gm...>: > > Why not doing a relase from ktl-0.3.7? > > Releasing something on sourceforge needs some rights. Currenly nobody > active on the list has them, as far as I know. > Ok... i understand, but just a svn branch working is enought for the people to compile it and have it running. > > > > > It works good enought for me, just need to fix the flowcode (changing 1 > line > > in fpnode) and fix some problems in pic simulation (changing 1 line in > > gpsimprocessor). > > I know it's a huge shame for me, but there are lots of mails in my > todo folder, for which I haven't got time to do. Exactly what to > change and where? > Well... here are the new lines: FIXING FLOWCODE: _____________________________________________________________________________ src/fpnode.cpp ,one line changed and some commented (around line 38) FlowPart *FPNode::outputFlowPart() const ......... ....... if( !m_outputConnector || !m_outputConnector->endNode() ) //if( m_outputConnector->endNode() == 0) // return 0; _____________________________________________________________________________ . FIXING PIC SIMULATION: _____________________________________________________________________________ src/electronics/gpsimprocessor.cpp , one line changed and some commented (around line 270): void GpsimProcessor::executeNext() ......... ........ ........ //if(get_bp().have_interrupt()) //{ // m_pPicProcessor->interrupt(); //} //else //{ m_pPicProcessor->step(1, false); // Don't know what the false is for, gpsim ignores its value anyway // Some instructions take more than one cycle to execute, //so ignore next cycle if this was the case if ( (get_cycles().get() - beforeExecuteCount) > 1 ) m_bCanExecuteNextCycle = false; //} ______________________________________________________________________________ > > There is also a bug when closing files directly shown in screen (created > in > > /temp/k.. ) that can be easily fixed (just don't creating a new temp > file). > > This is a new one for me. Which mail haven't I read? > Sorry i tought that this bug was reported, ktl crashes sometimes when closing a document. i did a fix that works for me, but this way when generating new documents that are not saved to disk (view directly) the last view will close and the new will open, then you can't have several views of this kind. This is not a real fix, just a workaround, but ktl don't crases. _____________________________________________________________________________ src/textview.cpp , some lines commented (at destructor): TextView::~TextView() { //if ( KTechlab::self() ) { // if ( KXMLGUIFactory * f = m_view->factory() ) // f->removeClient( m_view ); // // KTechlab::self()->addNoRemoveGUIClient( m_view ); //} delete m_pViewIface; } _____________________________________________________________________________ > > > > > For the piccomponent is not very difficult to add a property to choose > clock > > MHz and add a loop in simulator to manage speed. > > > > This is tricky. Some odd behaviour might occur if we have 2 loops in > the simulator. > Well... this a 5-step loop inside the logic loop, perhaps i'm wrong but it is working for me with any problems (by now). Anyway this should be examined for someone that knows ktl in deep. > > Running the qtimer at 10 ms does the simulation to go at real time for > me. > > > Changeing the simulator's "tick" period should be done one day. There > are quite a few issues with the simulator, starting from the total > lack of documentation about it. > > Ok, i know this issue should be improved one day, but personally i prefer having the simulation at real time today, and this just works for me: simulator.cpp __________________________________________________ stepTimer->start(10); const unsigned maxSteps = unsigned(LINEAR_UPDATE_RATE / 100); ______________________________________________________________ > I know there are a lot of people that wants to use Ktechlab for > educational > > purposes, but actually they can't find a ktechlab that works properly. > > > For instance me. And after seeing the codebase, I found this project > too challenging to not to join it. :)) > Yes... that's why i think is better having a ktl that works today than having nothing, even when it is not very accurate, but for educational purposes is enought if ktl doesn't crash and have flowcode and pic simulation working. Another cuestion that i made but didn't comment is replacing Microbe by GcBasic, that is a good open-source Basic compiler that support most of pics and have functions libraries... but i think this is out of this discussion. I did for my personal use and for some friends that want to use ktl in digital electronics teaching. |
From: Juan De V. <jua...@gm...> - 2009-10-10 04:59:14
|
Well guys, I know I'm not a developer, which seems to render any e-mail I send kind of useless to some of you, but I do have an opinion about what's being said, partly related to the other e-mail I sent a couple of days ago about the site. Many times it has been discussed on this list the topic of where is the project going, and every time it was agreed that nobody was very sure about that, and that nobody was also sure of how to organize things. I can tell you that even though I'm not a developer, I have been sort of studying the anatomy of a project from the open source view (I mean, I'm not talking about "professional", corporation style project management, cause that's just BS), and I think that if nobody is certain about how to do it, then the most logical thing would be to copy successful models, because if the project doesn't move forward by achieving goals, people, even you guys, will at some point get bored, besides the fact that instead of moving forward, things will more or less resemble a dog trying to catch it's own tale. So, I support Santiago's proposal of going for an official release, and I'd like to extend it with a few points I feel would help: 1.- Adopt a development cycle, which I think should be 6 months, just like that of KDE's itself. It could be more or less, but that would tie the project to the "release early, release often" principle. 2.- By releasing like that, users will be able to test the software, and they could find things not even you guys are aware of. Just check out Alan's e-mail. 3.- Set clear goals for every development cycles. This should be divided into bugfixing and feature adding. Just put things on the table, discuss and decide to work together on one aspect, one bug or one code section and work together on that until it has been solved, or at least works, there's always time for improvement later, the important thing is to always move forward. 4.- There shouldn't be only one codebase, but two at least, one for Production and testing and the second one for playground (also from KDE's model), so you avoid creating new bugs if just trying something. 5.- There should not only be a bug tracking system, but a feature request one. That is something I could take care of if I get the green light for the website. 6.- One more thing I offer myself to take care of, is to make some publicity of the software, and that is why I feel the website should be given more importance, it is what everyone wanting to learn more about the project itself sees. I could start to go around electronics websites and forums and invite people to check out the project. I don't think people gets a very good impression of the project today from that point of view. 7,- At some point, despite personal opinions, KTechLab should officially start moving towards QT 4 and KDE 4, and give everyone an option to use this great tool. I don't claim to hold all the truth, I insist, I'm totally aware that I'm not a developer, but I do feel involved with this project, and I'd love to see it succeed. I just hope this e-mail does not get ignored, and at least serves the purpose of starting a useful discussion about where it should go. I have a lot of ideas for the site and some other things, but I have felt utterly ignored up until now, because some people seems to not talk to non-developers, or just people that doesn't see the world as they do. Let me remind you how Julian Baume, one very active developer, valuable as a developer and as a team member, ended up working alone on a port to KDE 4, and finally stopped collaborating because he was being ignored as well. Regards, Juan On Fri, Oct 9, 2009 at 11:19 PM, santiago gonzalez <san...@gm...> wrote: > Why not doing a relase from ktl-0.3.7? > > It works good enought for me, just need to fix the flowcode (changing 1 line > in fpnode) and fix some problems in pic simulation (changing 1 line in > gpsimprocessor). > There is also a bug when closing files directly shown in screen (created in > /temp/k.. ) that can be easily fixed (just don't creating a new temp file). > > For the piccomponent is not very difficult to add a property to choose clock > MHz and add a loop in simulator to manage speed. > > Running the qtimer at 10 ms does the simulation to go at real time for me. > > I know there are a lot of people that wants to use Ktechlab for educational > purposes, but actually they can't find a ktechlab that works properly. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > |
From: Alan G. <ag...@sp...> - 2009-10-10 15:53:08
|
Juan De Vincenzo wrote: > Well guys, I know I'm not a developer, which seems to render any > e-mail I send kind of useless to some of you, but I do have an opinion > about what's being said, partly related to the other e-mail I sent a > couple of days ago about the site. You are now the project manager, congrats. ;) > I have a lot of ideas for the site and some other things, but I have > felt utterly ignored up until now, because some people seems to not > talk to non-developers, or just people that doesn't see the world as > they do. Let me remind you how Julian Baume, one very active > developer, valuable as a developer and as a team member, ended up > working alone on a port to KDE 4, and finally stopped collaborating > because he was being ignored as well. !!! I didn't know that. I always read his postings with great interest and I don't think I ever failed to pay him compliments. I even tried to stay away from working on the GUI code when I knew he was making radical changes. This is most distressing because I thought there was already good progress on the KDE4 front. That means we need to recruit a new KDE4 expert and see if we can con him into working on the ungodly monstrosity of highly customized Qt3.0(or older) code which is ktechlab... -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Juan De V. <jua...@gm...> - 2009-10-10 16:38:44
|
On Sat, Oct 10, 2009 at 12:50 PM, Alan Grimes <ag...@sp...> wrote: > Juan De Vincenzo wrote: >> Well guys, I know I'm not a developer, which seems to render any >> e-mail I send kind of useless to some of you, but I do have an opinion >> about what's being said, partly related to the other e-mail I sent a >> couple of days ago about the site. > > You are now the project manager, congrats. ;) Instead of ironically disqualifying my statements and systematically ignore certain parts of the e-mail, you could propose some other path. Oh, and given your reply, it would have been more complete if put like this: "You are now the pointy-haired project manager, congrats". You also proved me right. I wasn't talking of anything that you won't find on every successful Open Source project, even KDE has a board that decides the direction of the project. In my opinion, Alan, you just show what seems to be a misunderstood "hacker attitude" of disrespect to anybody you do not consider an equal. And that, more than a hacker attitude is a teenager "rebel without a cause" attitude. I will be working on the site, even though I don't know if anybody really cares, but I feel less welcome here every day. Regards, Pointy-Haired Juan, KTechLab's new Project Manager > > >> I have a lot of ideas for the site and some other things, but I have >> felt utterly ignored up until now, because some people seems to not >> talk to non-developers, or just people that doesn't see the world as >> they do. Let me remind you how Julian Baume, one very active >> developer, valuable as a developer and as a team member, ended up >> working alone on a port to KDE 4, and finally stopped collaborating >> because he was being ignored as well. > > !!! > > I didn't know that. I always read his postings with great interest and I > don't think I ever failed to pay him compliments. I even tried to stay > away from working on the GUI code when I knew he was making radical > changes. > > This is most distressing because I thought there was already good > progress on the KDE4 front. That means we need to recruit a new KDE4 > expert and see if we can con him into working on the ungodly monstrosity > of highly customized Qt3.0(or older) code which is ktechlab... > > > -- > New president: Here we go again... > Chemistry.com: A total rip-off. > Powers are not rights. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Zoltan P. <zol...@gm...> - 2009-10-10 16:57:40
|
Where is Jason when we need him? There are quite a few things to do on the sourceforge project. (1) Also I haven't heard about Lawrence Shafer for a while. If we want to upload some content to ktechlab.org, we should contact him. (2) More text inline follows: 2009/10/10, Juan De Vincenzo <jua...@gm...>: > Well guys, I know I'm not a developer, which seems to render any > e-mail I send kind of useless to some of you, but I do have an opinion > about what's being said, partly related to the other e-mail I sent a > couple of days ago about the site. > > Many times it has been discussed on this list the topic of where is > the project going, and every time it was agreed that nobody was very > sure about that, and that nobody was also sure of how to organize > things. I can tell you that even though I'm not a developer, I have > been sort of studying the anatomy of a project from the open source > view (I mean, I'm not talking about "professional", corporation style > project management, cause that's just BS), and I think that if nobody > is certain about how to do it, then the most logical thing would be to > copy successful models, because if the project doesn't move forward by > achieving goals, people, even you guys, will at some point get bored, > besides the fact that instead of moving forward, things will more or > less resemble a dog trying to catch it's own tale. > > So, I support Santiago's proposal of going for an official release, > and I'd like to extend it with a few points I feel would help: > Official release: it should be ready, but see problem (1) > 1.- Adopt a development cycle, which I think should be 6 months, just > like that of KDE's itself. It could be more or less, but that would > tie the project to the "release early, release often" principle. > We should define a "stable" base to start from... maybe the 0.3.7 is suitable. > 2.- By releasing like that, users will be able to test the software, > and they could find things not even you guys are aware of. Just check > out Alan's e-mail. > Note: Some packages / nightly builds would be nice. Julian Baume tried to build some packages at a moment. > 3.- Set clear goals for every development cycles. This should be > divided into bugfixing and feature adding. Just put things on the > table, discuss and decide to work together on one aspect, one bug or > one code section and work together on that until it has been solved, > or at least works, there's always time for improvement later, the > important thing is to always move forward. > > 4.- There shouldn't be only one codebase, but two at least, one for > Production and testing and the second one for playground (also from > KDE's model), so you avoid creating new bugs if just trying something. > This model IMHO works best in GIT style code repositories. We have just to move patches around. Currently there are some branches / tags for stable and trunk for everything else. > 5.- There should not only be a bug tracking system, but a feature > request one. That is something I could take care of if I get the green > light for the website. > See (1) and maybe (2) > 6.- One more thing I offer myself to take care of, is to make some > publicity of the software, and that is why I feel the website should > be given more importance, it is what everyone wanting to learn more > about the project itself sees. I could start to go around electronics > websites and forums and invite people to check out the project. I > don't think people gets a very good impression of the project today > from that point of view. > Again (2) :( > 7,- At some point, despite personal opinions, KTechLab should > officially start moving towards QT 4 and KDE 4, and give everyone an > option to use this great tool. > Sounds very well in theory, but this means a _lot_ of work. And for instance I have very little free time to help this project (studies...). > I don't claim to hold all the truth, I insist, I'm totally aware that > I'm not a developer, but I do feel involved with this project, and I'd > love to see it succeed. I just hope this e-mail does not get ignored, > and at least serves the purpose of starting a useful discussion about > where it should go. > > I have a lot of ideas for the site and some other things, but I have > felt utterly ignored up until now, because some people seems to not > talk to non-developers, or just people that doesn't see the world as > they do. Let me remind you how Julian Baume, one very active > developer, valuable as a developer and as a team member, ended up > working alone on a port to KDE 4, and finally stopped collaborating > because he was being ignored as well. > Sad and true :( At the end of the discussion we should note the conclusions on some webpage, but --again--, see (1) and (2). > Regards, > Juan > > On Fri, Oct 9, 2009 at 11:19 PM, santiago gonzalez <san...@gm...> > wrote: >> Why not doing a relase from ktl-0.3.7? >> >> It works good enought for me, just need to fix the flowcode (changing 1 >> line >> in fpnode) and fix some problems in pic simulation (changing 1 line in >> gpsimprocessor). >> There is also a bug when closing files directly shown in screen (created >> in >> /temp/k.. ) that can be easily fixed (just don't creating a new temp >> file). >> >> For the piccomponent is not very difficult to add a property to choose >> clock >> MHz and add a loop in simulator to manage speed. >> >> Running the qtimer at 10 ms does the simulation to go at real time for me. >> >> I know there are a lot of people that wants to use Ktechlab for >> educational >> purposes, but actually they can't find a ktechlab that works properly. >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Jason L. <jas...@nt...> - 2009-10-14 08:53:35
|
On Sat, 2009-10-10 at 18:57 +0200, Zoltan Padrah wrote: > Where is Jason when we need him? There are quite a few things to do > on the sourceforge project. (1) > OK Guys, I'm still listening. I'm just busy with other aspects of my life (don't ask!). What do you need me to do? J. |
From: Zoltan P. <zol...@gm...> - 2009-10-15 10:13:09
|
In my opinion it would be really useful to introduce redundancy in the management of the project, so all the times somebody will have a litte time to manage things around the project. I'm thinking to something like define a few project admins, which should write to the list before doing anything to the sourceforge project. Maybe you have better idea how to fix this problem; not having a leader sometimes is demoralizing. The actual todo list starts with: - update on sourceforge the latest release / snapshot - decide where to have the project's wiki (sourceforge has wiki option for projects, AFAIK) - set up proper links between the sourceforge project and ktechlab.org - project promoting ( some more items can be found for sure on the list arhives... ) In long term fix the "dayli" issues and encourage people to involve in the project 2009/10/14, Jason Lucas <jas...@nt...>: > > On Sat, 2009-10-10 at 18:57 +0200, Zoltan Padrah wrote: > > Where is Jason when we need him? There are quite a few things to do > > on the sourceforge project. (1) > > > OK Guys, I'm still listening. I'm just busy with other aspects of my > life (don't ask!). > > What do you need me to do? > > J. > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: P Z. <zol...@gm...> - 2009-11-01 19:41:51
|
On Sat, 10 Oct 2009 06:59:01 +0200, Juan De Vincenzo <jua...@gm...> wrote: > > I have a lot of ideas for the site and some other things, but I have > felt utterly ignored up until now, because some people seems to not > talk to non-developers, or just people that doesn't see the world as > they do. I also have some, not very clear ideas, but I'm very time limited (this will be so only until march, hopefully). I'd like to start a discussion (I hope this reply is not too late...). The next thing I want to do is to make release, but first I have to read some documentation about how exactly to do it... |
From: Alan G. <ag...@sp...> - 2009-10-10 23:59:35
|
Juan De Vincenzo wrote: > On Sat, Oct 10, 2009 at 12:50 PM, Alan Grimes <ag...@sp...> wrote: >> Juan De Vincenzo wrote: >>> Well guys, I know I'm not a developer, which seems to render any >>> e-mail I send kind of useless to some of you, but I do have an opinion >>> about what's being said, partly related to the other e-mail I sent a >>> couple of days ago about the site. >> You are now the project manager, congrats. ;) > > Instead of ironically disqualifying my statements and systematically > ignore certain parts of the e-mail, you could propose some other path. > Oh, and given your reply, it would have been more complete if put like > this: "You are now the pointy-haired project manager, congrats". You > also proved me right. I wasn't talking of anything that you won't find > on every successful Open Source project, even KDE has a board that > decides the direction of the project. > > In my opinion, Alan, you just show what seems to be a misunderstood > "hacker attitude" of disrespect to anybody you do not consider an > equal. And that, more than a hacker attitude is a teenager "rebel > without a cause" attitude. > > I will be working on the site, even though I don't know if anybody > really cares, but I feel less welcome here every day. > > Regards, > Pointy-Haired Juan, KTechLab's new Project Manager =( I think you're projecting your own self-doubts on me. If I was trying to be sarcastic, I would have used the =P smiley. I didn't. Nobody was maintaining ktechlab so I loaded it into kdevelop and now I'm the lead developer of the analog side of the code. You found that nobody was managing ktechlab and turned around to make some good suggestions. Guess what? That makes you the project manager. =P oops, I didn't mean it sarcastically just now but that's simply how things work. If you show you have a talent for something, such as management, you get to do it in the open source world. There are no corporate politics, no vetting of resumes, you just pick up the reigns and do it. You are the new project manager because nobody else is doing the job. I don't want the job, obviously I'm unsuited for it. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Juan De V. <jua...@gm...> - 2009-10-17 16:30:50
|
Well, a week has gone by already, but I didn't wanted to fail to send a reply to Alan. But I didn't had the faintest idea on what to say until about tuesday. I guess a good start would be to say this: I'm sorry. I reacted like that because, as I said on the e-mail, I felt that my suggestions were always ignored, and the only time you replied to me it really seemed to by an ironic reply, it really felt like that until you cleared the mean of your words. > I think you're projecting your own self-doubts on me. I would call them doubts, but that the concept I have. Maybe I'm wrong, but for me Project Manager is the opposite to a title one should hold proudly, that guy is the one that has little contact with the actual work but thinks he knows everything, and gives people "advice" on how to do their work. Regards, Juan On Sat, Oct 10, 2009 at 8:57 PM, Alan Grimes <ag...@sp...> wrote: > Juan De Vincenzo wrote: >> On Sat, Oct 10, 2009 at 12:50 PM, Alan Grimes <ag...@sp...> wrote: >>> Juan De Vincenzo wrote: >>>> Well guys, I know I'm not a developer, which seems to render any >>>> e-mail I send kind of useless to some of you, but I do have an opinion >>>> about what's being said, partly related to the other e-mail I sent a >>>> couple of days ago about the site. >>> You are now the project manager, congrats. ;) >> >> Instead of ironically disqualifying my statements and systematically >> ignore certain parts of the e-mail, you could propose some other path. >> Oh, and given your reply, it would have been more complete if put like >> this: "You are now the pointy-haired project manager, congrats". You >> also proved me right. I wasn't talking of anything that you won't find >> on every successful Open Source project, even KDE has a board that >> decides the direction of the project. >> >> In my opinion, Alan, you just show what seems to be a misunderstood >> "hacker attitude" of disrespect to anybody you do not consider an >> equal. And that, more than a hacker attitude is a teenager "rebel >> without a cause" attitude. >> >> I will be working on the site, even though I don't know if anybody >> really cares, but I feel less welcome here every day. >> >> Regards, >> Pointy-Haired Juan, KTechLab's new Project Manager > > =( > > I think you're projecting your own self-doubts on me. If I was trying to > be sarcastic, I would have used the =P smiley. I didn't. Nobody was > maintaining ktechlab so I loaded it into kdevelop and now I'm the lead > developer of the analog side of the code. > > You found that nobody was managing ktechlab and turned around to make > some good suggestions. Guess what? That makes you the project manager. > =P oops, I didn't mean it sarcastically just now but that's simply how > things work. If you show you have a talent for something, such as > management, you get to do it in the open source world. There are no > corporate politics, no vetting of resumes, you just pick up the reigns > and do it. You are the new project manager because nobody else is doing > the job. I don't want the job, obviously I'm unsuited for it. > > > -- > New president: Here we go again... > Chemistry.com: A total rip-off. > Powers are not rights. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Alan G. <ag...@sp...> - 2009-10-11 00:08:00
|
Zoltan Padrah wrote: >> There is also a bug when closing files directly shown in screen (created in >> /temp/k.. ) that can be easily fixed (just don't creating a new temp file). > > This is a new one for me. Which mail haven't I read? > >> For the piccomponent is not very difficult to add a property to choose clock >> MHz and add a loop in simulator to manage speed. > This is tricky. Some odd behaviour might occur if we have 2 loops in > the simulator. I'm pretty sure PIC Components already are handled in the simulator. There are about 4 lines having to do with them. I haven't done anything to them because I'm not into digital. it should be possible to rework that so that it can synchronize with the >> Running the qtimer at 10 ms does the simulation to go at real time for me. > Changeing the simulator's "tick" period should be done one day. There > are quite a few issues with the simulator, starting from the total > lack of documentation about it. Have you seen the current SVN head version of the simulator? It's considerably simpler than the previous versions and should be easier to grok. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: santiago g. <san...@gm...> - 2009-10-11 02:03:58
|
2009/10/11 Alan Grimes <ag...@sp...> > Zoltan Padrah wrote: > >> There is also a bug when closing files directly shown in screen (created > in > >> /temp/k.. ) that can be easily fixed (just don't creating a new temp > file). > > > > This is a new one for me. Which mail haven't I read? > > > >> For the piccomponent is not very difficult to add a property to choose > clock > >> MHz and add a loop in simulator to manage speed. > > > This is tricky. Some odd behaviour might occur if we have 2 loops in > > the simulator. > > I'm pretty sure PIC Components already are handled in the simulator. > There are about 4 lines having to do with them. I haven't done anything > to them because I'm not into digital. it should be possible to rework > that so that it can synchronize with the > Yes, the loop i'm talking about is just there, that lines you mention is a "for loop" that call every gpsimprocessor and run 1 step in gpsim. the only thing the loop does is: depending on the clock speed of each piccomponent 1,2,3,4 or 5 steps will be executed on gpsim in every logic update. But for this to work a new property is needed in piccomponent to choose the clock speed, and two new functions in gpsimprocessor like: set_clocksteps() to call from piccomponent and get_clocksteps() to call from simulator. This is the way i did, but i'm sure there are better ones. This is just a workaround, not a real solution to run pics at realtime, but i think this is better than runing the pic a a fixed rate of 1e6 steps/s (=4MHZ pic clock) > >> Running the qtimer at 10 ms does the simulation to go at real time for > me. > > > Changeing the simulator's "tick" period should be done one day. There > > are quite a few issues with the simulator, starting from the total > > lack of documentation about it. > > Have you seen the current SVN head version of the simulator? It's > considerably simpler than the previous versions and should be easier to > grok. > > > -- > New president: Here we go again... > Chemistry.com: A total rip-off. > Powers are not rights. > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Lawrence S. <det...@gm...> - 2009-10-15 17:39:45
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I *think* sourceforge let the wiki system go, last I heard.<br> <br> Zoltan Padrah wrote: <blockquote cite="mid:259...@ma..." type="cite"> <div>In my opinion it would be really useful to introduce redundancy in the management of the project, so all the times somebody will have a litte time to manage things around the project. I'm thinking to something like define a few project admins, which should write to the list before doing anything to the sourceforge project. Maybe you have better idea how to fix this problem; not having a leader sometimes is demoralizing.</div> <div> </div> <div>The actual todo list starts with:</div> <div>- update on sourceforge the latest release / snapshot</div> <div>- decide where to have the project's wiki (sourceforge has wiki option for projects, AFAIK)</div> <div> <div>- set up proper links between the sourceforge project and <a moz-do-not-send="true" onclick="return top.js.OpenExtLink(window,event,this)" href="http://ktechlab.org/" target="_blank">ktechlab.org</a></div> <div>- project promoting </div> ( some more items can be found for sure on the list arhives... )<br> </div> <div>In long term fix the "dayli" issues and encourage people to involve in the project</div> <div> </div> <div><span class="gmail_quote">2009/10/14, Jason Lucas <<a moz-do-not-send="true" onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:jas...@nt..." target="_blank">jas...@nt...</a>>:</span> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">On Sat, 2009-10-10 at 18:57 +0200, Zoltan Padrah wrote:<br> > Where is Jason when we need him? There are quite a few things to do<br> > on the sourceforge project. (1)<br> ><br> OK Guys, I'm still listening. I'm just busy with other aspects of my<br> life (don't ask!).<br> <br> What do you need me to do?<br> <br> J.<br> <br> <br> <br> ------------------------------------------------------------------------------<br> Come build with us! The BlackBerry(R) Developer Conference in SF, CA<br> is the only developer event you need to attend this year. Jumpstart your<br> developing skills, take BlackBerry mobile applications to market and stay<br> ahead of the curve. Join us from November 9 - 12, 2009. Register now!<br> <a moz-do-not-send="true" onclick="return top.js.OpenExtLink(window,event,this)" href="http://p.sf.net/sfu/devconference" target="_blank">http://p.sf.net/sfu/devconference</a><br> _______________________________________________<br> Ktechlab-devel mailing list<br> <a moz-do-not-send="true" onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Kte...@li..." target="_blank">Kte...@li...</a><br> <a moz-do-not-send="true" onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a><br> </blockquote> </div> <br> <pre wrap=""> <hr size="4" width="90%"> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/devconference">http://p.sf.net/sfu/devconference</a></pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ Ktechlab-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Kte...@li...">Kte...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a> </pre> </blockquote> <br> </body> </html> |
From: P Z. <zol...@gm...> - 2009-10-16 16:43:51
|
It seems they recommend using wiki or blog: http://sourceforge.net/apps/trac/sourceforge/wiki/Get%20started%20with%20your%20new%20project#Step4:Launchyourwikiorblog see also: http://sourceforge.net/apps/trac/sourceforge/wiki/Hosted%20Apps On Thu, 15 Oct 2009 19:42:16 +0200, Lawrence Shafer <det...@gm...> wrote: > I *think* sourceforge let the wiki system go, last I heard. > > Zoltan Padrah wrote: > > In my opinion it would be really useful to introduce redundancy in the > management of the project, so all the times somebody will have a litte > time to > manage things around the project. I'm thinking to something like define > a few > project admins, which should write to the list before doing anything to > the > sourceforge project. Maybe you have better idea how to fix this problem; > not > having a leader sometimes is demoralizing. > ---snip--- |