I started using Redcar a couple days ago as my primary text editor for programming on my Ubuntu machine. It's definitely a buggy software, and it's obvious that it's still in development, but overall I like it more than anything else I've come across. That said, I just discovered that I apparently can't do any more than 10 or so undos with the software. Even worse, I wasn't able to figure out any way to change this limit. This is kind of a dealbreaker for me, since I routinely write lots of code that I then choose to revert to something I had only a minute earlier.
Does anybody know if there is any way to raise this limit? Alternatively, does anybody know any other comparable text-editors for Linux? One of the most important features for me that any software I use needs to have is the ability to show me where a partner bracelet/bracket/parenthesis is when I move the cursor (or rather, whatever the keyboard equivalent of the cursor is called) onto it. I'm writing software that uses lots of callbacks, nested if statements, and nested loops, so I need to be able to easily tell where corresponding structures are in my code.
Best, and thanks in advance for any responses,Sami
Related
I'm very lost with this matter, so sorry if I'm asking for something too obvious or something, but I've been trying to get some low level info about it and, for what I've seen till now, I wouldn't even know where to start...
Anyway, the case is I'm trying to develop a tool script in Lua that I'd like at some point could be able to do some very basic interaction with a webpage, e.g. for downloading/looking for updates and little more. I'm already aware Lua can't do any of this per se (even I think it totally should at this time of life, but that would be another discussion 🙄), and the only ways I've read about pass for using external libraries/packages like LuaSocket or lua-http.
Well, besides all that external kind of stuff are far beyond my current capabilities in all the senses, how could I make them work anyway if I'm constrained to only can really do what the main app (Moho in this case, internally running Lua 5.2) allows me to do? Or as far as I know at least, because I remember at some point they added the possibility of extending some Lua possibilities by allowing access to a folder called modules where supposedly you could put your own libraries or whatever, not sure if even in form of DLLs, but besides that would also be another level to me, and there is zero documentation on that regard, once again I wouldn't even know where to start... Plus, if I'm going to have to build my own Lua compilation and include a lot of extra files, etc. for such a simple update checking feature... well, as much as I'd like its implementation, it simply could not worth all the mess.
So, once exposed, what do you think are really my changes of getting this super-basic internet interaction from my pure Lua script? Are really 0 as I'm afraid, or do you think I could not be considering other possible ways even if they were not the more efficient or recommendable?
Everyone is aware of Dijkstra's Letters to the editor: go to statement considered harmful (also here .html transcript and here .pdf). I was wondering is anyone attempted to find a way to make code using goto's re-usable and maintainable and not-harmful by adding any other language extensions or developing a language which allows for gotos.
The reason I ask the question is that it occurs to me that code written in Assembly language often used goto's and global variables to make the program work well within a limited space. The Atari 2600 which had 128 bytes of ram and the program was loaded from ROM cartridge. In this case, it was better to use unstructured programming and to make the most of the freedoms this allows to make the most of a very limited space for the program.
When you compare this with a game programmed today without the use of gotos, the game takes up much more space.
Then it occurs to me that perhaps its possible to program with the use of gotos if some rules or other language changes are made to support this, then the negative effects of gotos could be reduced or eliminated. Has anyone tried to find a way to make goto's NOT considered harmful by creating a language or some rules to follow which allow gotos to be not harmful.
If no-one looked for a way to use gotos in a non-harmful way then perhaps we adopted structured programming un-necessarily based solely on this paper? Perhaps there is another solution which allows for the use of gotos without the down-side.
Comparing gotos to structured programming is comparing a situation where the programmer has to remember what every labels in the code actually mean and do, and where there are, to a situation where the conditional branches are explicitly described.
As of the advantages of the goto statement regarding the place a program might take, I think that games today are big because of the graphic and sound resources they use. That is, show 1,000,000 polygons. The cost of a goto compared to that is totally neglectable.
Moreover, the structural statements are ultimately compiled into goto ("jmp") statements by the compiler when outputting assembly.
To answer the question, it might be possible to make goto less harmful by creating naming and syntax conventions. Enforcing these conventions into rules is however pretty much what structural programming does.
Linus Torvald argued once that goto can make source code clearer, but goto is useful in so very special cases that I would not dare use it as a programmer.
This question is somehow related to yours, since I think this one of the most common situations where a goto is needed.
we use a tool that operates on a certain database updating certain values when we makes some changes to the tool.
This takes a long time for some simple task.
I just need to find out which table,column and the value for that column gets updated.
for this i need to find out the whole database which column_name has value "XYZ" and the corresponding table/tables.
Any scripts for these.
Just because something can be done does not mean it should be done.
I know you've got your process designed this way and you very likely don't want to change it but, really, your life will get a whole lot better if you redesign this to avoid doing something that really, seriously, shouldn't be done. Searching through every text field in an entire database in search of some magical character string is a Bad Idea. It's actually only ONE of The Big Bad Ideas and it probably isn't the Baddest Idea, but it's a big enough bad enough idea that you should give Serious Consideration to doing something else, better.
OK, so what's wrong with it?
First, it indicates that you're not using a database, you're using a midden. You dump stuff in and then hope to dig it out later. This is the kind of thing people did thousands of years ago (it was popular back when flint was cutting edge technology), and while it helps keep archaeologists employed digging through these trash heaps, we are software developers, not archaeologists, and we don't want to have to do this kind of thing on a regular basis.
Second, this is a serious performance killer. You're going to either write some god-awful static code to laboriously check every field in every table, or you're going to write some middling-bright code to dynamically create some even more god-awful query that will laboriously check every field in every table. The word to focus on here is "laborious". And "god-awful", if it comes to that. Scanning through every row in every table in your database and testing every field in all of those every rows is going to be slow. Very, very slow. It's going to be dead-turtle-on-the-side-of-the-road-with-tire-marks-on-its-shell slow. This is not a good thing to do, unless you own stock in the local electric utility and want to make sure every generated electron has a happy home in your employers computer.
Third, people will have strong emotions when they see your code. Those destined for careers in management will laugh, for they know that they won't have to maintain it or try to solve the performance issues. The technically challenged will cry, because they'll know there's nothing they can do to fix it. The true Code Warriors will stare in amazement for a moment, and will then grit their teeth, hunt you down, and beat you to death with their ceremonial Wands Of Green-Bar, for only they will know that this evil could have been prevented.
So give some thought to a re-design. Once again, just because something can be done does not mean it should be done.
Share and enjoy.
Currently we are facing following Problem in our Application:
Around 40 % of the Code that is in the Application is never used. That means the Code would be there, and maybe functional, but the Frontend Feature has been shut off so the Users cannot reach the Functionality anymore or other Methods are replacing the old, now deprecated Methods.
What i am currently doing is removing all the old code while not trying to break anything, manually.
The Question is:
Would you remove the old Code, or hope that it may awake some time ... zombie - like
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Should we keep the Code somewhere, as a reference? ( We are using Version Control, but i find it is pretty hard to find old code in the Revision Jungle ... any tips for that? )
Do you have arguments for convincing the team / management / developers that wrote said code?
Reasons to not deprecate and then delete Code?
TL;DR: Delete unused code or leave it as it is? Discuss!
u
If you are certain that the code is unused, definitely delete it. I assume you have a version control system, so if you ever need it again, you can still find the code back.
Deleting the unused code will make the project easier to maintain, and your team probably will end up saving time in the long run (nobody will re-read the code to try and understand what it was used for, nobody will end up changing said code thinking it may still be used...)
However, if your code contains a public API that is distributed, you will probably want to mark the classes/methods deprecated for some time before effectively deleting the code, so the callers have some time to adapt (or inform you of the issue).
Would you remove the old Code, or hope that it may awake some time ... zombie - like
I'd definitely remove it. I hate having to work out if functions ever get called.
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Yes, definitely worth the effort.
Should we keep the Code somewhere, as a reference?
Um, you are using version control softwarev, aren't you?
I have recently been put in charge of debugging two different programs which will eventually need to share an XML parsing script, at the minimum. One was written with PureMVC, and another was built from scratch. While it made sence, originally, to write the one from scratch (it saved a good deal of memory, but the memory problems have since been resolved).
Porting the non-PureMVC application will take a good deal of time and effort which does not need to be used, but it will make documentation and code-sharing easier. It will also lower the overall learning curve. With that in mind:
1. What should be taken into account when considering whether it is best to move things to one standard?
(On a related note)
Some of the code is a little odd. Because the interpreting App had to convert commands from one syntax to another, it made sense to have an interpreter Object. Because there needed to be communication with the external environment, it made more sense to have one object interact with the environment, and for that to deal with the interpreter exclusively.
Effectively, an anti-Singleton was created. The object would only interface with the interpreter, and that's it. If a member of another class were to try to call one of its public methods, the object would raise an Exception.
There are better ways to accomplish this, but it is definitely a bit odd. There are more standard means of accomplishing the same thing, though they often involve the creation of classes or class files which are extraordinarily large. The only solution which I could find that was standards compliant would involve as much commenting and explanation as is currently required, if not more. Considering this:
2. If some code is quirky, but effective, is it better to change it to make it less quirky, even if it is made a more unwieldy?
In my opinion this type of refactoring is often not considered in schedules and can only be done when there is extra time.
More often than not, the criterion for shipping code is if it works, not necessarily if it's the best possible code solution.
So in answer to your question, I try and refactor when I have time to do so. Priority One still remains to produce a functional piece of code.
Things to take into account:
Does it work as-is?
As Galwegian notes, this is the only criterion in many shops. However, IMO just as important is:
How skilled are the programmers who are going to maintain it? Have they ever encountered nonstandard code? Compare the cost of their time to learn it (including the cost of delayed dot releases) to the cost of your time to refactor it.
If you're maintaining it, then instead consider:
How much time will dealing with the nonstandard code cost you over the intended lifecycle of the codebase (e.g., the time between now and when the whole thing is rewritten)?
That's hard to guess, but consider that many codebases FAR outlive the usefulness envisioned by their original authors. (Y2K anyone?) I've gradually developed a sense of when a refactoring is worthwhile and when it's not, mostly by erring on the side of "not" too often and regretting it later.
Only change it if you need to be making changes anyway. But less quirky is always a good goal. Most of the time spent on a particular piece of software is in maintenance, so if you can do something to make that easier, you'll be reducing the overall time spent on that piece of code. Nonetheless, don't change something if it's working and doesn't need any modifications.
If you have time, now. If you don't have time and it can be avoided, later.