Re: D dropped in favour of C# for PSP emulator
On Saturday, 19 May 2012 at 01:33:55 UTC, Jesse Phillips wrote: On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote: So just starting up the IDE is more important than actually writing code or fixing bugs?... I'd like to see you do those things without starting your IDE. Seriously, I'm never going to understand you "editor" people.. My oversimplification of it is, IDEs like the fundamental component of writing software. A text editor. Sure it has this text insertion thing, but it just looks like they forgot about it. I'll have to agree. You can skip the editor entirely and use nothing but cat, or Joe but I personally have not; I make too many mistakes on a single pass usually. Having a good base working environment that is both easy to use, and combines everything you need in one spot is actually quite crucial; and this does include an editor which may (hopefully) be part of an IDE. True I can probably do all the C/C++/D programming I want in notepad++, but doing all the extra work manually or only being able to rely on the language reference without any intellisense or something does leave a bit of a problem. The biggest deterrent to using D/D2 up to now was lacking a good debugger. With VisualD around I have just enough in the VS IDE to write and use my own code; True it has a lot of work to be done on it, but It's usable. An improved IDE and debugger later will greatly speed up not only bug fixing but programming in general using D.
Re: Posix vs. Windows
On Saturday, 19 May 2012 at 06:47:48 UTC, H. S. Teoh wrote:
One day it's bound to happen, though.
Yeah I'd heard about some similar stuff too, waiting to hear
about it.
Substitute "length(" with "size(" instead of just "length" with
"size". Problem solved. :-)
Er, you missed the entire point of my example. :\
Those were PROPERTIES. They are used *without* parentheses. Your
solution doesn't actually work on them. :P
Worse yet, no way in hell that a command-line tool would tell
you your documentation is messed up. :P
Oh yeah? And what about when documentation mentions the old
name of the method? In which case you *want* to rename it. :-)
My answer might suprise you then... you should _REALLY_ try using
a real IDE to get a feel for what I'm talking about.
Eclipse actually _automatically renames_ identifiers inside your
documentation comments.
All it takes is Alt+Shift+R to say you want to rename an
identifier, and it corrects all references _as you type_.
With 100% accuracy, I might add. Unlike the CLI-based solution,
it's NOT a half-baked text-based solution. AFAIK it uses the
syntax tree.
Try doing that in
:P
I did say it's clunky. But it's also a trivial case that one
quickly learns and remembers how to deal with correctly. :-)
Again, see above.
Your solution fails miserably when you're working with properties
like In my example, since those don't have any parentheses.
Plus, you've to keep in mind that integration with arbitrary
shell commands add a whole new dimension to this that no
Windows-centric IDE can ever hope to achieve.
+1 yes, it's powerful indeed. But they're all text-based.
Editing source code with text-based tools is error-prone. Editing
them with an IDE that uses the syntax tree is not.
Simple as that.
It is possible in theory
key word here :P^
Thing is, in vim the various movement keys can be applied as
modifiers to a particular action. And because these are logical
entities, not physical positions, the same command can be
applied to vastly different parts of the text and still have
the same logical meaning. That is, 2 paragraphs in this case
may span 6 lines, but in another part of the file it may span 8
lines.
Yes, that's very powerful. But again, it's for *TEXT*, not CODE.
Unless your editor can go "two scopes down and six statements to
the right", what you're saying doesn't really work for code (or
maybe I'm not understanding it right?).
Eeek! On most modern keyboards, PgUp/PgDn, etc., are so far out
of the way that you might as well reach for the mouse.
Lol, 100% correct -- except in my situation. :P
I code on my laptop, and it's Fn+Up and Fn-Down. Home/End are
Fn-Left and Fn-Right.
Takes a little getting used to at the beginning, but it's VERY
handy. :)
Especially compared to ESC, as you mentioned.
Yikes. I wouldn't touch Windows 7 with a 20-foot sterilized
flagpole. XP was the last usable version of Windows in many
senses of the word.
If you haven't used it then you can't really say that now, can
you? (If you're thinking of Vista when you think of 7, FYI it's
on the opposite end of the spectrum from Windows 7. And if you
don't like the looks, you can always switch to an XP-like theme,
like me.)
There's a reason the adoption rate of Windows 7 is
significantly slower than MS would like.
I thought it was doing well?
But yeah I just swallowed your chunk of salt, thanks. :P
Now don't get me wrong, Ubuntu is doing a very good thing in
making Linux accessible to the masses, but frankly, you haven't
_really_ used Linux until you've mastered the command-line and
can regularly compose long chains of pipes that does magical
transformations to data without thinking twice. In my previous
job, there was a part-time contractor who regularly writes
5-line long bash commands complete with subshells, multiple
redirections, obscure sed/grep tricks, AND HAVE IT ALL WORK THE
FIRST TIME ROUND WITHOUT NEEDING TO HIT BACKSPACE EVEN ONCE.
Seriously, the guy just breathes bash command lines like a fish
in water,
My God, how I wish I could do that! :O As much as I'm not a Linux
fan, I still want that ability -- it can be very *very* useful in
quite a few situations!!
it's uncanny. Sometimes you just stare at him compose these
incredibly complex commands and your jaw just drops to the
floor in amazement. Your first thought is "that can't possibly
work! Isn't that a typo right there?! He spelt that option
wrong!" and then the next second, your eyes are popping out of
their sockets, "what the... it WORKED?!?!?!".
I've seen 1 person who did stuff *close* to what you're
describing... and yes, my jaw dropped indeed, so I know what you
mean perfectly. it's... out of this world... x___x
Sufficiently advanced shell commands are indistinguishible from
physics-defying magic. ;-)
+1
(If you've ever had to deal with the monstrosities that are
makefiles for very large (>2 m
Re: [OT] Windows users: Are you happy with git?
Happy with Mercutial (CLI), Windows family and OpenSUSE ;)
Re: [OT] Windows users: Are you happy with git?
On Saturday, 19 May 2012 at 02:05:54 UTC, Ary Manzana wrote: On 5/18/12 9:03 PM, Jacob Carlborg wrote: On 2012-05-18 16:01, Manu wrote: On 18 May 2012 16:41, Alex Rønne Petersen mailto:a...@lycus.org>> wrote: But to be fair, most enterprises/businesses use Linux for servers, not for desktops. I don't code on a server... Do you? :) Why use source code management and deploys when you can code directly on the production server :) Where's the "like" button here? :-P LMFAO
Re: Posix vs. Windows
On 19.05.2012 3:03, H. S. Teoh wrote: On Fri, May 18, 2012 at 11:08:26PM +0200, Mehrdad wrote: On Friday, 18 May 2012 at 19:40:35 UTC, H. S. Teoh wrote: This is one of those things that makes Windows (l)users wonder how we Unix people can stand using the shell all day -- their idea of shell is the DOS prompt (a veritable train wreck of train wrecks). If only they knew what a *real* shell can do. ;-) Don't generalize. :P Well, that was partially tongue-in-cheek. ;-) I'm a Windows user, but yes, I've used Linux and yes, the command prompt is indeed a train wreck. Bash is indeed a lot better. And no, I haven't used PowerShell; I hate programs that take too long to start up. Whoa. PowerShell takes a long time to start up? Sounds like it's already a train wreck even before you start using it. Far is the command line for windows. And a decent editor, and ftp client that doesn't suck and.. -- Dmitry Olshansky
Re: Posix vs. Windows
On 19/05/2012 00:51, H. S. Teoh wrote: On Sat, May 19, 2012 at 01:21:56AM +0200, Mehrdad wrote: On Friday, 18 May 2012 at 23:02:18 UTC, H. S. Teoh wrote: I find IDEs more painful to use than scratching your nails on a chalkboard. The inability of running an IDE over a remote SSH session without everything slowing down to a snail crawl makes it completely unusable for me. Have you tried running Eclipse/Visual Studio over Remote Desktop on Windows? I don't use Windows except when I have to fix my wife's windows laptop. :-P Was it actually that slow? Anything that has a GUI is unacceptably slow over a remote connection, last time I checked. I'm not talking about connecting over a local network, which doesn't really count, but a connection over the internet. If you want to see _real_ slowness, try opening in MS Access (running locally) a .mdb that is on a fileserver accessed via a VPN connection. That's what they briefly made me do in one of my recent jobs. It works on Linux as well, and it's amazing. (Not quite as powerful as Emacs/Vim, but it's hella more intuitive/easier to use, so worth it IMO.) "Intuitive" text editors are ultimately also limited by their intuitiveness, because what most people think of as "intuitive" is "what I type appears on the screen" and "I don't have to memorize obscure key sequences to get stuff done". No, because such an editor could still provide obscure key sequences for those advanced features that are beyond what can reasonably be done with an intuitive GUI. Whatever those advanced features are. Stewart.
Re: Posix vs. Windows
On May 18, 2012, at 5:39 PM, "Mehrdad" wrote: > > Yeah, imagine trying to name a method named "getValue()" to something else > (probably because you realized that's not a great name :P). > > A HUGE time waster without refactoring tools, and last time I checked, no > text-based tool did it. Possibly because this can be accomplished from the command line with find/grep/sed and the like.
Re: Posix vs. Windows
On May 18, 2012, at 7:10 PM, "Mehrdad" wrote:
>
> 2. Okay, so that's clever. :P Now tell me what you do when you have dozens of
> lines in your source file like
>
>@property auto length() { return _range.length; }
>
> and you want to rename the field 'length'? How do you prevent the second one
> from getting renamed?
sed using a regex that accounts for more of the line than just "length", like "
length(". It only gets tricky if you are renaming a method call with a
non-unique name, which is when you need to use compiler output to flag the
offending lines since pure text analysis won't cut it.
> Or say you have
>
>@property auto back() { ... }
>@property moveBack() { assert(0, "Cannot move an element from the back!");
> }
>auto popBack() { }// Remove an element from the back
>
> and you change the name of the property 'back' to 'last':
>
>@property auto back() { ... }
>@property moveBack() { assert(0, "Cannot move an element from the last!");
> }
>auto popBack() { }// Remove an element from the last
>
> Notice something funny?
Three operations, one for each method actually being renamed. Ultimately, it's
hard to replace a real refactoring tool since it has a compiler built-in
though. That said, I don't personally do this kind of thing... pretty much
ever. So using a special tool when needed seems like an option.
Re: Posix vs. Windows
On Saturday, 19 May 2012 at 13:49:28 UTC, Sean Kelly wrote:
On May 18, 2012, at 7:10 PM, "Mehrdad"
wrote:
2. Okay, so that's clever. :P Now tell me what you do when you
have dozens of lines in your source file like
@property auto length() { return _range.length; }
and you want to rename the field 'length'? How do you prevent
the second one from getting renamed?
sed using a regex that accounts for more of the line than just
"length", like " length(". It only gets tricky if you are
renaming a method call with a non-unique name, which is when
you need to use compiler output to flag the offending lines
since pure text analysis won't cut it.
Somehow I fail to see how this is more productive than doing a
"rename method"
option.
Re: stream interfaces - with ranges
Sorry, I have updated it. Run 'make runbench' or 'make runbench_opt'. Kenji Hara 2012/5/19 Artur Skawina : > On 05/18/12 17:43, kenji hara wrote: >> I'm designing experimental IO primitives: >> https://github.com/9rnsr/dio > >> It has a sample benchmark to compare performance with std.stdio for >> line iteration. > > It's not exactly what i had i mind, but i tried to build it; > it wants a 'io/wrapper.d' module which can not be found. > > artur
Re: Posix vs. Windows
On May 19, 2012, at 7:00 AM, "Paulo Pinto" wrote:
> On Saturday, 19 May 2012 at 13:49:28 UTC, Sean Kelly wrote:
>> On May 18, 2012, at 7:10 PM, "Mehrdad" wrote:
>>> 2. Okay, so that's clever. :P Now tell me what you do when you have dozens
>>> of lines in your source file like
>>> @property auto length() { return _range.length; }
>>> and you want to rename the field 'length'? How do you prevent the second
>>> one from getting renamed?
>>
>> sed using a regex that accounts for more of the line than just "length",
>> like " length(". It only gets tricky if you are renaming a method call with
>> a non-unique name, which is when you need to use compiler output to flag the
>> offending lines since pure text analysis won't cut it.
>>
>
> Somehow I fail to see how this is more productive than doing a "rename method"
> option.
It isn't necessarily more efficient. But most editors don't have a compiler
built-in, and the ones that do aren't always practical to use.
Re: MBCS character code support
16.05.2012 8:26, Alex Rønne Petersen написал: On 16-05-2012 06:18, Katayama Hirofumi MZ wrote: On Wednesday, 16 May 2012 at 04:12:04 UTC, Alex Rønne Petersen wrote: I really do not understand why you want to use Shift-JIS. Unicode has long superseded all these magical encodings used all over the world. Why oppose a unified encoding? On Windows 9x, there is no Unicode support. Instead, native MBCS encoding exists. So, if the D Windows program could use UTF-8 only, then the programmer should let the D program convert these strings to Shift_JIS. D does not support Windows versions older than Windows 2000. D2 has no Windows 2000 support for a long time. http://d.puremagic.com/issues/show_bug.cgi?id=6024 https://github.com/D-Programming-Language/druntime/pull/212 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Method pointers are *function* pointers?? Or delegates??
Le 19/05/2012 03:37, Daniel Murphy a écrit :
"Mehrdad" wrote in message
news:ifswigmcenyryxzyv...@forum.dlang.org...
On Friday, 18 May 2012 at 18:59:23 UTC, Steven Schveighoffer wrote:
On Fri, 18 May 2012 14:30:46 -0400, Andrei Alexandrescu
wrote:
On 5/18/12 1:22 PM, Mehrdad wrote:
My brain just exploded.
Can someone explain what's going on?
class Test
{
public void foo() { }
}
static assert(is(typeof(&Test.foo) == void function()));
Looks like a bug. The assert should pass only if foo were static.
No, this is not a bug.
The purpose is so you can get the function pointer portion of a delegate
without an instance of the object.
I actually realized that might be the reason before I reported this, but
then I thought:
In that case, shouldn't the 'this' parameter be explicitly part of the
function (at the end of the parameter list)?
No, that won't work in all cases due to the ordering of parameters, 'this'
and the hidden struct pointer.
extern(this) and you are done expressing thiscall.
Re: Method pointers are *function* pointers?? Or delegates??
Le 18/05/2012 22:35, Andrei Alexandrescu a écrit :
On 5/18/12 1:59 PM, Steven Schveighoffer wrote:
On Fri, 18 May 2012 14:30:46 -0400, Andrei Alexandrescu
wrote:
On 5/18/12 1:22 PM, Mehrdad wrote:
My brain just exploded.
Can someone explain what's going on?
class Test
{
public void foo() { }
}
static assert(is(typeof(&Test.foo) == void function()));
Looks like a bug. The assert should pass only if foo were static.
No, this is not a bug.
It is.
The purpose is so you can get the function pointer portion of a delegate
without an instance of the object.
Typing is what it is. The following program is unsound without a cast in
sight:
class Test
{
void foo() { writeln("foo"); }
}
static assert(is(typeof(&Test.foo) == void function()));
void fun()
{
writeln("fun");
}
void main() {
alias void function() TFun;
TFun a = &fun;
a();
a = &Test.foo;
a();
}
At best things could be arranged that &Test.foo has type void
function(Test) or something.
Andrei
It would be nice, but require a way to express that calling convention
(thiscall is often different than simply passing an argument).
I proposed extern(this).
This would have the extra benefice of being able to declare UFCS with
thiscall convention.
If the extern isn't added, the feature must go, it is made to write bugs.
Possible bug in the D compiler w.r.t x86_64 ABI calling convention
Hi, I seem to have discovered a bug in the D compiler which is causing it to emit incompatible code with gcc on Ubuntu 11.04 x86_64. I have minimised the code required to reproduce this problem and uploaded it to github, here is the link https://github.com/SDX2000/CFromDTest1. Once you have downloaded it run build to generate the executables. You'll see that the output produced by the d program is different from the output produced by the equivalent c code. I have spent some time on analysing the generated assembly. You'll find annotated assembly code main.d etc highlighting the problem. Basically the problem is that dmd generates code which is not compatible with gcc when a C function returns a struct. Please do let me know if this is a legitimate bug and if I need to file a bug report. Regards, Sandeep Datta.
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Saturday, 19 May 2012 at 18:31:45 UTC, Sandeep Datta wrote: Please do let me know if this is a legitimate bug and if I need to file a bug report. x86_64 struct ABI differences are a known problem and being worked on, a fix will likely be included with the next release. David
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Saturday, 19 May 2012 at 18:37:20 UTC, David Nadlinger wrote: On Saturday, 19 May 2012 at 18:31:45 UTC, Sandeep Datta wrote: Please do let me know if this is a legitimate bug and if I need to file a bug report. x86_64 struct ABI differences are a known problem and being worked on, a fix will likely be included with the next release. David Hmm, are there any known work arounds? I am in a fix as I need to use the demios/libclang wrapper but it has several functions which return structs.
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Saturday, 19 May 2012 at 18:41:28 UTC, Sandeep Datta wrote: On Saturday, 19 May 2012 at 18:37:20 UTC, David Nadlinger wrote: On Saturday, 19 May 2012 at 18:31:45 UTC, Sandeep Datta wrote: Please do let me know if this is a legitimate bug and if I need to file a bug report. x86_64 struct ABI differences are a known problem and being worked on, a fix will likely be included with the next release. David Hmm, are there any known work arounds? I am in a fix as I need to use the demios/libclang wrapper but it has several functions which return structs. Oops...hit send a little too early...I guess building with -m32 should fix this problem, no?
Re: stream interfaces - with ranges
On Friday, 18 May 2012 at 19:18:21 UTC, Artur Skawina wrote: On 05/18/12 20:18, Artur Skawina wrote: On 05/18/12 17:43, kenji hara wrote: I'm designing experimental IO primitives: https://github.com/9rnsr/dio It has a sample benchmark to compare performance with std.stdio for line iteration. It's not exactly what i had i mind, but i tried to build it; it wants a 'io/wrapper.d' module which can not be found. And is apparently windows-only; missing HANDLE type, non- existent TextOutputRange. I gave up after running into: io/file.d:263: Error: static assert (isSource!(File)) is false Current dio is PoC for new IO design. If we go with such design, I will add Linux/Mac support to dio. Masahiro
Re: stream interfaces - with ranges
Please add README to top directory. (Contents are benchmark command, support environment and etc) We can see such information on web browser ;) P.S. I want to do pull request for supporting other environments. But I'm busy right now... Masahiro On Saturday, 19 May 2012 at 15:22:37 UTC, kenji hara wrote: Sorry, I have updated it. Run 'make runbench' or 'make runbench_opt'. Kenji Hara 2012/5/19 Artur Skawina : On 05/18/12 17:43, kenji hara wrote: I'm designing experimental IO primitives: https://github.com/9rnsr/dio It has a sample benchmark to compare performance with std.stdio for line iteration. It's not exactly what i had i mind, but i tried to build it; it wants a 'io/wrapper.d' module which can not be found. artur
Re: scope ref const(T) --> error?!
http://d.puremagic.com/issues/show_bug.cgi?id=8121
Re: Posix vs. Windows
Am 19.05.2012 15:35, schrieb Sean Kelly: On May 18, 2012, at 5:39 PM, "Mehrdad" wrote: Yeah, imagine trying to name a method named "getValue()" to something else (probably because you realized that's not a great name :P). A HUGE time waster without refactoring tools, and last time I checked, no text-based tool did it. Possibly because this can be accomplished from the command line with find/grep/sed and the like. While wiping everything else that is also called getValue() along the way, even if they belong to instances of other classes. I like UNIX and the command line is invaluable for certain tasks regardless of the operating system, but sometimes I wonder if people realized that it is no longer 1970 and better ways to develop software do exist. -- Paulo
Re: Posix vs. Windows
On Saturday, 19 May 2012 at 19:28:44 UTC, Paulo Pinto wrote: I like UNIX and the command line is invaluable for certain tasks regardless of the operating system, but sometimes I wonder if people realized that it is no longer 1970 and better ways to develop software do exist. …especially because it would be perfectly possible to provide a command-line interface to »intelligent« (i.e. frontend-backed) refactoring tools as well. David
Re: Posix vs. Windows
On Sat, May 19, 2012 at 09:45:20AM +0200, Mehrdad wrote:
> On Saturday, 19 May 2012 at 06:47:48 UTC, H. S. Teoh wrote:
[...]
> >Substitute "length(" with "size(" instead of just "length" with
> >"size". Problem solved. :-)
>
>
> Er, you missed the entire point of my example. :\
>
> Those were PROPERTIES. They are used *without* parentheses. Your
> solution doesn't actually work on them. :P
OK, I concede. :)
> >>Worse yet, no way in hell that a command-line tool would tell you
> >>your documentation is messed up. :P
> >
> >Oh yeah? And what about when documentation mentions the old name of
> >the method? In which case you *want* to rename it. :-)
>
> My answer might suprise you then... you should _REALLY_ try using a
> real IDE to get a feel for what I'm talking about.
>
> Eclipse actually _automatically renames_ identifiers inside your
> documentation comments.
> All it takes is Alt+Shift+R to say you want to rename an identifier,
> and it corrects all references _as you type_.
> With 100% accuracy, I might add. Unlike the CLI-based solution, it's
> NOT a half-baked text-based solution. AFAIK it uses the syntax tree.
Now that _is_ pretty cool.
Actually I've been thinking about this kind of problems. It's not just
code, actually, the problem is much more general than that. It applies
to _any_ structured text.
See, the thing is, one of the reasons I like vim in spite of its warts
(yes it has warts, including what we're discussing here about syntax
trees transformations) is that it gives me a _unified_ environment for
working with all kinds of files: text files, XML files, configuration
files with their own syntax, code in all kinds of languages, other files
with formatted syntax, Python (hehe), and even my 4-dimensional esolang.
The unification is very convenient: no need to switch between 15
different tools to work with different file formats. Better yet, you can
do things like quote code in emails, write cross-language code, etc.,
without flinching.
But this unification is also its downfall: plain text, as the lowest
common denominator, also suffers from not being able to deal with syntax
trees in a meaningful way.
So what is needed is a way of plugging in arbitrary syntax tree parsers,
such that you can have a generic editing environment which can handle
any structured text, not just code, but _anything_ that can be parsed.
You then have a basic core of text-editing operations, plus semantic
operations that work with the syntax trees directly.
Now vim actually does have plugin capability, though I'm not sure if
it's general enough to do what I just described.
> Try doing that in
>
> :P
Don't be shocked if you find a vim plugin that does just that. ;-)
> >I did say it's clunky. But it's also a trivial case that one quickly
> >learns and remembers how to deal with correctly. :-)
>
> Again, see above. Your solution fails miserably when you're working
> with properties like In my example, since those don't have any
> parentheses.
True.
> >Plus, you've to keep in mind that integration with arbitrary shell
> >commands add a whole new dimension to this that no Windows-centric
> >IDE can ever hope to achieve.
>
>
> +1 yes, it's powerful indeed. But they're all text-based.
>
> Editing source code with text-based tools is error-prone. Editing them
> with an IDE that uses the syntax tree is not.
>
> Simple as that.
It would be really cool if there were syntax tree manipulators that
could do stuff like that. Actually, thinking a bit more about what I
wrote above, what if there were external parser programs that can do
these kinds of transformations, then you can just invoke them to do
their magic when you need syntax-tree based manipulations. A text editor
really should just do one thing: edit text. With full command-line
integration, you can even bind certain operations to external utilities
that specialize in whatever language/format they're designed to deal
with. Unix philosophy: every program does one thing, and does it really
well; connect them together, and you can do stuff no individual program
can hope to do, even stuff none of the authors of said programs even
imagined possible.
> >It is possible in theory
>
> key word here :P^
Ah, but isn't that what we programmers specialize in? Turning theory
into reality. ;-)
> >Thing is, in vim the various movement keys can be applied as
> >modifiers to a particular action. And because these are logical
> >entities, not physical positions, the same command can be applied to
> >vastly different parts of the text and still have the same logical
> >meaning. That is, 2 paragraphs in this case may span 6 lines, but in
> >another part of the file it may span 8 lines.
>
> Yes, that's very powerful. But again, it's for *TEXT*, not CODE.
> Unless your editor can go "two scopes down and six statements to the
> right", what you're saying doesn't really work for code (or maybe I'm
> not understanding it right?).
Actually, vim does have s
Re: Posix vs. Windows
On Sat, May 19, 2012 at 09:43:13PM +0200, David Nadlinger wrote: > On Saturday, 19 May 2012 at 19:28:44 UTC, Paulo Pinto wrote: > >I like UNIX and the command line is invaluable for certain tasks > >regardless of the operating system, but sometimes I wonder if > >people realized that it is no longer 1970 and better ways to > >develop software do exist. > > …especially because it would be perfectly possible to provide a > command-line interface to »intelligent« (i.e. frontend-backed) > refactoring tools as well. [...] +1. I think the ideal development environment would be one where there are reusable parsers and syntax-tree rewriters (either standalone programs or libraries with generic API), that can be used to do semantic-level text manipulations, which can then be used with basic text-editing functions. I envision something like this (using vim as an example, substitute your favorite editor at will): have a bunch of language-specific plugins, like xml, c, c++, d, etc., for basic syntax-tree level navigation through source code, bound to a bunch of designated syntax-tree navigation keys in the editor, plus a bunch of language-specific operations (like rename identifiers, move nested function in/out of nesting, etc.) bound to some kind of command interface, which can be aliased to unused command keys. These plugins can be applied to arbitrary blocks of text -- usually an entire buffer, but possibly to sections within a buffer, such as D code embedded in an email, or XML embedded in a heredoc, etc.. The plugins autodetect the environment they're in, much like vim already does nowadays to a limited extent, but you can also bind specific plugins to sections of text at will. Now you have an environment that lets you work on all kinds of files in all kinds of formats, with basic text editing capability common to all of them, plus semantic actions for language-specific operations. Best of all, these plugins have a common, generic API, that can be reused by _anything_. Imagine if you can, for example, grep for stuff in a large source tree and have grep automatically detect the language of a particular file so that it can use a plugin for locating stuff at specified places in a syntax tree. You'd then be able to do really handy stuff like "find this regex in the body of for loops that are nested inside a top-level function", or "enumerate all occurrences of if-statements nested at least 3 levels deep". T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: Posix vs. Windows
On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote:
Now that _is_ pretty cool.
:D yes!
See, the thing is, one of the reasons I like vim in spite of
its warts (yes it has warts, including what we're discussing
here about syntax trees transformations) is that it gives me a
_unified_ environment for working with all kinds of files
Indeed, that's one of the major reasons people use text editors
over IDEs for a lot of tasks.
Don't be shocked if you find a vim plugin that does just that.
;-)
I dunno, I might be xD
It would be really cool if there were syntax tree manipulators
Omg yeah. And I think D is probably the closest to getting
something like that.
I remember asking about whether something like this this in
StackOverflow, but (perhaps because I didn't phrase myself
properly) people didn't really understand what I was saying and I
kinda got blank responses lol.
Ah, but isn't that what we programmers specialize in? Turning
theory into reality. ;-)
Touche
Actually, vim does have some rudimentary support for moving
across scopes. I don't know about statements, though.
Yeah, editors often have brace-matching and stuff ("go to
matching/enclosing brace") but yeah, not statements.
Honestly, I like the layout better (the standard PC keyboard is
way too wide). However, the _size_ of a laptop keyboard is just
too uncomfortable for me
Yup, I've been debating if I want a real-sized keyboard or not...
might order one these days. :)
OK I admit I was being unfair. See, my problem is, the second I
have to deal with rodent navigation and clicking through menus,
I just get really really frustrated that I can't just tell the
stupid machine to do what I already know I want to do.
Totally understand what you mean -- I could say the same thing
for *nix tools, just the other way around. (Why can't I *browse*
my choices? why do I have to look at /documentation/, for God's
sake, to figure out how to just locate a file on my computer?
etc.)
Yikes!!
Indeed, that says it all. xD
You do realize that building GCC involves two stages, right?
Someone told me like a year later. XD
http://www.vim.org/scripts/script.php?script_id=301
Ah, the wonders of opensource. :-)
:) I have a love-hate relationship with OS. It's among the
greatest things in CS but it also has its own problems. I was
going to post a link to a blog post I read about it, but while I
agree with it, it's a little harsher than my view, so maybe not.
xD
Yikes! I highly recommend using plain vanilla vim, no GUI
Oh geez, that'll take a while lol. At least with GVim, I can
discover the command names through the menus haha.
Re: D dropped in favour of C# for PSP emulator
On 18 May 2012 19:59, Bruno Medeiros wrote: > On 12/05/2012 01:00, Timon Gehr wrote: > >> some essential properties: >> - starts up instantaneously >> > > > some 'nice to have' properties: >> - code analysis based code completion >> > > - integrated debugger > > So just starting up the IDE is more important than actually writing code > or fixing bugs?... > > Seriously, I'm never going to understand you "editor" people.. No, writing code and fixing bugs is more important than sitting around and operating your computer. I can hit F7 or F5 way faster than I can type a full line of some command on the shell. I can tap tab and instantly complete typing the crap I waste time typing repeatedly (typing almost all identifiers become just 1 or 2 key strokes). I can hit ctrl-space and have the documentation for a function appear INSTANTLY much faster than I can swap out and refer to some reference manual. I can step and debug and inspect the value of variables, deep in structures containing a heap of indirection way faster than I can operate GDB. I will seriously never understand anyone who will try and honestly say typing shit on a command line, feeding commands to GDB manually, and looking up references in some external manual can possibly be faster... under ANY circumstances... ever.
Re: Posix vs. Windows
H. S. Teoh wrote: > But this unification is also its downfall: plain text, as the lowest > common denominator, also suffers from not being able to deal with syntax > trees in a meaningful way. > > So what is needed is a way of plugging in arbitrary syntax tree parsers, > such that you can have a generic editing environment which can handle > any structured text, not just code, but _anything_ that can be parsed. > You then have a basic core of text-editing operations, plus semantic > operations that work with the syntax trees directly. > You mean like Emacs' Semantic mode? https://www.gnu.org/software/emacs/manual/html_node/emacs/Semantic.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Posix vs. Windows
On Saturday, 19 May 2012 at 20:58:40 UTC, Jérôme M. Berger wrote: You mean like Emacs' Semantic mode? https://www.gnu.org/software/emacs/manual/html_node/emacs/Semantic.html O_O
Re: D dropped in favour of C# for PSP emulator
On Saturday, 19 May 2012 at 20:42:13 UTC, Manu wrote: On 18 May 2012 19:59, Bruno Medeiros wrote: On 12/05/2012 01:00, Timon Gehr wrote: some essential properties: - starts up instantaneously some 'nice to have' properties: - code analysis based code completion > - integrated debugger So just starting up the IDE is more important than actually writing code or fixing bugs?... Seriously, I'm never going to understand you "editor" people.. No, writing code and fixing bugs is more important than sitting around and operating your computer. I can hit F7 or F5 way faster than I can type a full line of some command on the shell. I can tap tab and instantly complete typing the crap I waste time typing repeatedly (typing almost all identifiers become just 1 or 2 key strokes). I can hit ctrl-space and have the documentation for a function appear INSTANTLY much faster than I can swap out and refer to some reference manual. I can step and debug and inspect the value of variables, deep in structures containing a heap of indirection way faster than I can operate GDB. I will seriously never understand anyone who will try and honestly say typing shit on a command line, feeding commands to GDB manually, and looking up references in some external manual can possibly be faster... under ANY circumstances... ever. Perhaps to be a hard-core hacker? I've done a GUI-less programming before, using GDB, typing the commands, all that jazz. But it's about the same as jogging to work every day that's say 15 Miles away; you 'COULD' do it, but if there's a better way like a bike or a car or segway, then why continue to do it the longer more busy route? With a good editor and having data 10-50x faster and more available, you can get more work done, and thereby fix more bugs and program more. You'd have to actually use a decent IDE (like eclipse for java) to realize how useful it can be. Course if you have an awesome memory then perhaps it isn't quite as important; but honestly I have a horrible memory.
Lazy evaluation of function arguments in D
http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
Re: Posix vs. Windows
On May 19, 2012, at 1:35 PM, "Mehrdad" wrote: > On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote: > >> Yikes! I highly recommend using plain vanilla vim, no GUI > > Oh geez, that'll take a while lol. At least with GVim, I can discover the > command names through the menus haha. The only way to really learn vim is to suffer through it until it clicks. The experience is so fundamentally different than other editors, that menus would just prevent that from happening. That said, some editors, like Sublime Text 2 (my current favorite) have a vi mode that functions pretty closely to how vi does. It's another way to ease your way into the vi mindset, as it were. Personally, I know enough vi to get around but not enough to prefer it. It's simy a matter of necessity though, as vi is the only editor I've found installed on every system I need to edit on. Too bad it couldn't at least be vim though.
dmd link mystery on linux
I'm having a problem where the link command line generated by dmd is picking up the globally-installed version of the phobos library instead of my local one. I'm using a dmd.conf pointing at my local phobos build so this shouldn't be happening. From output of "dmd rdmd.d -v": gcc rdmd.o -o rdmd -m64 -Xlinker -L/home/john/dev/d/phobos/generated/linux/release/64 -lphobos2 -lpthread -lm -lrt which looks right to me (referenced dir contains libphobos2.a). I know this is picking up the wrong phobos2 because the globally-installed version is missing some required symbols. If I move the global .a out of the way my local lib is picked up and the link and subsequent run are fine. More strangely, if I remove -Xlinker from that link line my local lib is again picked up. From my understanding, omitting -Xlinker causes gcc to interpret the -L option natively. Does anyone know why this would make a difference, or can anyone point out what I'm missing? Also, I'm wondering if anyone else would find it useful for the update.sh tool to automatically generate a dmd.conf which points to the local druntime and phobos.
Re: Lazy evaluation of function arguments in D
http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/c4pwvyp +1 ^
Re: Lazy evaluation of function arguments in D
On Sunday, 20 May 2012 at 00:26:14 UTC, Mehrdad wrote: http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/c4pwvyp +1 ^ Yeah, I'd like both "lazy" and "ref" to be forced to be used from the call site >and not just in the declaration. I don't use lazy that often but I would use >'ref' more often if I could tell from the call site that my arguments might be >modified. IMO requiring caller to specify ref, out or lazy would make D programs more robust and easier to understand. And it is clearly much easier, than, for example, would be repeating pure, nothrow, safe, or even contracts at each call (any of these would not make sence for me because they are enforced by the compiler). Sorry if the above is confusing, I have difficulties to explain it more clearly.
Re: Lazy evaluation of function arguments in D
On Saturday, 19 May 2012 at 23:03:50 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/ Lazy evaluation has been discussed previously, but this topic is important and the problems have not been solved yet. Functional languages, like Haskel, Scala or F#, have the semantics of lazy evaluation which is to evaluate things at most once. Evaluating many times is accomplished via a function or delegate. Thus lazy in D is (IMO): * confusing, because it doesn't take into account lazy semantics * close to useless, because functions or delegates could do the same job and not confuse the users * somehow hiding the need to have the functionality of evaluating an expression at most once. For example, I need this to work with immutable data, but it is not possible conceptually at this moment (clearly, evaluating and storing the result would mutate the data). I understand that designing this would mean there is the need for synchronization for immutable data. But at least this functionality could exist for pure functions.
Re: Posix vs. Windows
On Sat, May 19, 2012 at 04:53:32PM -0700, Sean Kelly wrote: > On May 19, 2012, at 1:35 PM, "Mehrdad" wrote: > > > On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote: > > > >> Yikes! I highly recommend using plain vanilla vim, no GUI > > > > Oh geez, that'll take a while lol. At least with GVim, I can > > discover the command names through the menus haha. > > The only way to really learn vim is to suffer through it until it > clicks. The experience is so fundamentally different than other > editors, that menus would just prevent that from happening. Exactly. Until you've grappled with GUI-less vim, you haven't _really_ used vim. I did say that it was a very frustrating experience for me. But when it clicked, it _really_ clicked. Now I couldn't bear to use pico or joe or any of that stuff. They've become so foreign to me. It's one of those things that have a totally steep learning curve, but totally worth it once you get it. Just like console Linux/bash. (Even I myself find it hard to believe, but there was a time when I used to _hate_ Linux. Yeah.) Or ratpoison (aka how to use a GUI without a mouse). :-P > That said, some editors, like Sublime Text 2 (my current favorite) > have a vi mode that functions pretty closely to how vi does. It's > another way to ease your way into the vi mindset, as it were. > Personally, I know enough vi to get around but not enough to prefer > it. It's simy a matter of necessity though, as vi is the only editor > I've found installed on every system I need to edit on. Too bad it > couldn't at least be vim though. Ugh. Plain vi (non-vim) is a bear to use. Many non-vim vi's have an undo buffer with a depth of 1. And it just goes downhill from there. :-P But at least, once you've eased into the vim mindset, you can navigate around inferior vi's without stumbling into electric fences and stubbing your toes. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: Posix vs. Windows
Am 20.05.2012 07:43, schrieb H. S. Teoh: [...] That said, some editors, like Sublime Text 2 (my current favorite) have a vi mode that functions pretty closely to how vi does. It's another way to ease your way into the vi mindset, as it were. Personally, I know enough vi to get around but not enough to prefer it. It's simy a matter of necessity though, as vi is the only editor I've found installed on every system I need to edit on. Too bad it couldn't at least be vim though. Ugh. Plain vi (non-vim) is a bear to use. Many non-vim vi's have an undo buffer with a depth of 1. And it just goes downhill from there. :-P But at least, once you've eased into the vim mindset, you can navigate around inferior vi's without stumbling into electric fences and stubbing your toes. T One thing I hate is visiting customers which have UNIX installations configured with their default installs. Depending on the operating system version, sometimes I feel like I am back in 197x, with the original versions of vi, sh, sed, and so on. The people that only have GNU/Linux or BSD experience, don't have any idea how spoiled they are when compared with the commercial UNIX vendors offerings. -- Paulo
