Jump to content

Black Pearl

Members
  • Posts

    410
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Black Pearl

  1. There is a tool (search the forums) that is trying brute force attack. If your pw is weak enough, you might give it a try. But it also might be dependend on your LV version, if it is still possible or blocked by the dev enviornment. Felix
  2. Don't forget that the vanilla way in most text based OOP languages is the by-ref design. These cowboys like to shoot around with pointers instead of keeping all safe on the wire. If I were to create a Fewton'O'Eight, I also would consider a queue, create 8 objects and store them in the queue. Whenever a request is received, dequeue one of these objects. Whenever a object is returned, enqueue it again. I think this approach is simpler than the array (because the objects are not ordered). Felix
  3. It is on the german wikipedia in the article about design patterns (right after singleton) http://de.wikipedia.org/wiki/Erzeugungsmuster In the artcle about Singleton, another variant is mentioned: the Multiton. Another ressource is the following implementation of the Fewtone (german text, but implementation is java/english) http://www.junit-buch.de/doc/fewton.html I also found some real examples why you want to have a Fewton. If you have a limited ressource available (network bandwidth), you want to limit the number of processes (number of downloads, torrents ...) that access these, but to a number >1. Felix
  4. I encountered the word 'fewton' on wikipedia yesterday (it indeed is a 'singletone'-style object that has a limited number of maximum instances >1). Felix
  5. When using VI Server over entwork, connect to the App.Instance of the other PC. I don't remember the details, but I think it was just as easy to start the LV runtime... Felix
  6. To add some more pro's to the OpenG ini VIs: If you change the parameters you only need to change the cluster type def of these parameters, OpenG handles all the File stuff automagically. Felix
  7. When they moved into their new house, they didn't like the door bell. I did fix it, but blamed here: you are the EE! This ain't not me domain! She propably realized it and now here husband is taking care of the kids... Felix
  8. Tough topic, but face the situation: Computer 'geeks' have no idea about 'gender-studies', and 'gender-studies'-persons have no ideas of computers/geeks. And this is based on simple equations like 'gender-studies'=females(historical feminist background required) and 'computers/geeks'=males(we already call it software, what else do you girls want from us?). But I just want to leave this challenge to the academia staff to solve. Here just some info I can throw in: * In CS the western countries have a very bad gender ration about (guess) 95% male: 5% female, while in such anti-women countries as Iran you have over 50% women in CS * a friend of mine (woman studying CS) tells me, that most of those 5% are non-western (coming from arabic or asian countries) -> so this seems to be a cultural issue * another friend of mine (she was trying tom revive women power) realized, that in 'free`communities such as Open Source projects, the gender ratio is even worse than in average CS industries (geek factor?) * a recent study showed that girls confronted with predjudices (girls are bad at math) performed worse in math tests than girls that were not confronted with these. * In engineering, a very big gain is community (think about our lovely LAVA community), but community building is gendered to women. How can we perform at all with that lack of female influence? BTW: My sister is VHDLing robots in a big company, geek? Felix
  9. I use dia (Open Source, still beta, leightweight) http://live.gnome.org/Dia I'm planning to post some more on this between the holidays, so stay tuned. Felix
  10. Paul, suggesting to use a variable (shared, global, whatever) to someone who is using AEs might result in a response like: 'Didn't we agree to use AE's instead of variables' or they will call the exorcist ('globals are evil'). Felix
  11. Ben: In my very long post I mentioned that AEs transmitt data wireless... Felix
  12. I'd say, that the AE is superseded by LVOOP. We shouldn't blame them as Anti-Patterns yet for reasons Ben mentioned (we got used to them) as well as issues we will face when we rewrite legacy code to be OOP. The main reason IMO for AEs is encapsulation. So I have a configuration data TD and a set of methods (load, save) and each of these methods (they might be SubVIs or inlined code) goes in one case of the AE. When you have a wide variety of parameters for the set of methods on the AE, you will get a messy interface, either due to a big cluster or a huge number of terminals or both... But we managed to deal with that by exposing the relevant parameters only with a set of Wrapper VIs (especially to mark the required inputs). So we have a hierarchy like this: n Wrapper VIs 1 AE with data in shift register m SubVis Using LVOOP we eliminate the AE layer having only the accessor methods (which is the level of the wrapper). n Public Accessor Methods 1 Private Data Cluster m SubVis OOP gives as some more benifites: * interface, so we have public and private (ok, we can do it also for AEs as suggested above, recently I was thinking of just postfixing VIs to mark it as public/private) * inheritance But there are differences between both designs, and these will still give the AE a place in our templates folder. Even more, these differences should warn us not to blindly replace AEs by OOP: * AEs are effectivily serializing the access to the data (or whatever we encapsulate). And it works even on a network scope as Bens experience tells. And all those 100s of posts about singelton design pattern (and I think no satisfying solution evolved yet) are a clear sign that the time of the AE is not yet over. Either we still think in AE serialization or this is a serious drawback that comes with OOP. My personal thinking is, that the singeltone debate will be solved by employing an AE (either encapsulating the Object or implementing the locking mechanism inside our class. * AEs transport the data wireless (that makes a good marketing slogan: 'transmitt your data wireless with Action Engines'). As such they are a good choice for passing data between parallel loops and between states in a SM when we don't want to sacrifice a shift register for that). This implies that an object replacing them must be based on a by-ref design, which still is evolving with the introduction of the DVR last summer. Current designs still suffer from the serialization we get for free with an AE, leading to race conditions and deadlocks. I'd conclude, AEs will become a less important design pattern as LV transforms into LVOOP. Maybe in some years, we will look at this design pattern like we look at stacked sequences today (legacy, but still rare/exotic use cases exist where they are correct to use). And as the rise of scripting languages (such as lua) in the text programmers world showed, the AEs might even come back as a way to 'Express program', which of course we all will reject publicly (LAVA shirts on NI week: 'No AEs required') and all will use for things like prototyping, QD-bugfixes (QD != quickdrop, QD=quick-and-dirty, hint: Darren, change the name for the sake of the marketing guys, they will all go crazy if the read this; if not, remind them that microsoft went big with Q-DOS when just removing the 'quick'). Felix
  13. There is two kinds of kinematic: Parallel and serial. Parallel kinematics distrubute the forces much better over the robot structure, so they will allow to make them lighter. But their reach is small (google for hexapod). They are also very difficult to design, so there is a few companies that might offer these. Serial kinematics is the classic arm. There also exist some hybrid solutions (3 axis parallel + a serial axis). If you are looking for the classic arm robot, the big ones in europe are ABB (white), Fanuc (yellow) and Kuka (orange). For sophisticated solutions I am impressed by Adept. I've once seen a 4-axis parallel-kinematics for pick and place tasks in action and I was really impressed. Felix
  14. Ton, hanks for that post. I use Mantis + SVN, but never made it that far (although I read about it). I will try to get that 'automagically' thing working next week... Felix
  15. Congratulations! And enjoy both the baby and the sleep. Felix
  16. I just realized that the dark side is already on dimension 15th. But all binary there... Felix
  17. Black Pearl

    Irony

    And installing some games eats much more of your disk space. They have their undocumented (so unusable for you) RTEs as well (physical modelling, ...). Felix
  18. But you still need to find a nice superhero avatar...
  19. More pictures, less text: http://www.tesladownunder.com/ Felix
  20. Seems like you were almost running up that hill. When hiking in the mountains, you should not go for the distance but for the elevation. With the data from the link you did 600m. Normal speed is 200m per hour. In my best time I did 200 m in about 45 min. Also hope you have good boots, as most accidents in the alps happen due to normal streetware. One day I was hiking in the swiss alps doing Arosa -> Davos and back on the same day (this is 1.200m up, 800m down and back, total distance about 50 km). It was already late afternoon so I had no time left to take another route, when I faced a very dangerous section. Everything was sliding down 200m and the trail was maybe 20 cm wide. I went crazy and could not walk that path. I ended up crawling on all 4 with closed eyes. Since then I suffer heavily from acrophobia. The best I ever did was the Tiger Leaping Gorge in China. Felix
  21. You should be able to use the built-in units of the controls. The user can change them by tyoing in mm, in, ft... Select visible->Unit Lable and type in mm. You will need to convert your data by cast to unit. Felix
  22. Tomi, got it. My basics in FP are long ago (haskel, some mathematica). We need to have a native 'map' function to go that way. But can't we? really? That would be the proof... Felix
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.