Re: Mono-D v0.4.8
and another bug: (I've updated to the correct stable version as per your instructions, since my last post included). Not sure how to reproduce this bug but it just happened after switching back to MD (i'm on OSX): A fatal error has occurred Details of this error have been automatically sent to Xamarin for analysis. MonoDevelop will now close. System.ArgumentOutOfRangeException: Argument is out of range. at MonoDevelop.D.Formatting.Indentation.IndentStack.Push (Inside inside, Byte keyword, Int32 lineNr, Int32 nSpaces) [0x0] in :0 at MonoDevelop.D.Formatting.Indentation.DIndentEngine.PushHash (Inside inside) [0x0] in :0 at MonoDevelop.D.Formatting.Indentation.DIndentEngine.Push (Char c) [0x0] in :0 at MonoDevelop.Ide.Gui.Content.DocumentStateTracker`1[MonoDevelop.D.Formatting.Indentation.DIndentEngine].UpdateEngine (Int32 position) [0x0015b] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Content/DocumentStateTracker.cs:130 at MonoDevelop.D.Formatting.Indentation.DIndentationTracker.GetIndentationString (Int32 offset, DocumentLocation loc) [0x0] in unknown>:0 at MonoDevelop.D.Formatting.Indentation.DIndentationTracker.GetIndentationString (Int32 lineNumber, Int32 column) [0x0] in :0 at MonoDevelop.D.Formatting.Indentation.DIndentationTracker.GetVirtualIndentationColumn (Int32 lineNumber, Int32 column) [0x0] in :0 at Mono.TextEditor.TextEditorData.GetVirtualIndentationColumn (DocumentLocation loc) [0x0] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/TextEditorData.cs:1073 at Mono.TextEditor.TextViewMargin.MousePressed (Mono.TextEditor.MarginMouseEventArgs args) [0x001fc] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/TextViewMargin.cs:1640 at Mono.TextEditor.TextEditor.OnButtonPressEvent (Gdk.EventButton e) [0x000a3] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/Mono.Texteditor/Mono.TextEditor/Gui/TextEditor.cs:1025 at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) [0x0] in :0
Re: Mono-D v0.4.8
A)
Awesome, again these problems - which MD version do you've got
installed?
3.0.6 stable? Then please switch to the
mono-d.alexanderbothe.com/stableMD repository
3.1.0 beta? Then switch to the mono-d.alexanderbothe.com repo.
OK, that made it work. Very low priority, but maybe it's possible
to provide 1 package that would work in both cases (if it were D,
something like version(MD_3_0_6){}else version(MD_310_beta)
else{...} but i guess it's C#).
B)
With code indent I'm not meaning code formatting but the
automated indentation generation after e.g. you've pressed
and it inserts 3 tabs because you're in a method of a
class of an other class.
thanks for finally tackling that! Now that the hard part is done,
couldn't there be a way to reindent the entire file (or
selection) upon request (control + I on OSX for format doc) by
calling this function on each line or something similar?
(temporary hack and might be a bit slow but a MUCH needed
feature).
C)
A question about your choice for C# vs D: wouldn't it have been
easier to write the bulk of your code in D and interface with the
MD codebase through some C wrappers? Assuming there's less than
100 or so functions you need to interface with... That way you'd
be able to benefit from hopefully soon to be written code
formatting, parsers, etc.
D)
BUG: I unchecked the option "insert * or + at comment new line"
but it still inserts "+" after a new line in a "/+" comment.
E)
BUG: create a new file, open it in MD (by double clicking for
example), press a key (eg "a"), it gives the following error (see
below). We can press OK and it'll work, but that's still a bug:
An error has occurred
Error in text editor extension chain
System.ArgumentNullException: Argument cannot be null.
Parameter name: key
at
System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[System.String]].TryGetValue
(System.String key, System.Collections.Generic.List`1& value)
[0x0] in :0
at
D_Parser.Resolver.ASTScanner.AbstractVisitor.HandleNonAliasedImport
(D_Parser.Dom.Import imp, MemberFilter VisibleMembers) [0x0]
in :0
at
D_Parser.Resolver.ASTScanner.AbstractVisitor.HandleDBlockNode
(D_Parser.Dom.DBlockNode dbn, MemberFilter VisibleMembers,
Boolean takePublicImportsOnly) [0x0] in :0
at D_Parser.Resolver.ASTScanner.AbstractVisitor.scanChildren
(D_Parser.Dom.DBlockNode curScope, MemberFilter VisibleMembers,
System.Boolean& breakOnNextScope, Boolean publicImports, Boolean
isBaseClass, Boolean isMixinAst, Boolean takeStaticChildrenOnly)
[0x0] in :0
at D_Parser.Resolver.ASTScanner.AbstractVisitor.ScanBlock
(IBlockNode curScope, CodeLocation Caret, MemberFilter
VisibleMembers, System.Boolean& breakOnNextScope) [0x0] in
:0
at D_Parser.Resolver.ASTScanner.AbstractVisitor.ScanBlockUpward
(IBlockNode curScope, CodeLocation Caret, MemberFilter
VisibleMembers) [0x0] in :0
at
D_Parser.Resolver.ASTScanner.AbstractVisitor.IterateThroughScopeLayers
(CodeLocation Caret, MemberFilter VisibleMembers) [0x0] in
:0
at
D_Parser.Resolver.ASTScanner.MemberCompletionEnumeration.EnumAllAvailableMembers
(ICompletionDataGenerator cdgen, IBlockNode ScopedBlock,
IStatement ScopedStatement, CodeLocation Caret,
D_Parser.Misc.ParseCacheList CodeCache, MemberFilter
VisibleMembers, D_Parser.Resolver.ConditionalCompilationFlags
compilationEnvironment) [0x0] in :0
at
D_Parser.Completion.CtrlSpaceCompletionProvider.BuildCompletionDataInternal
(IEditorData Editor, System.String EnteredText) [0x0] in
:0
at
D_Parser.Completion.AbstractCompletionProvider.BuildCompletionData
(IEditorData Editor, System.String EnteredText) [0x0] in
:0
at
D_Parser.Completion.AbstractCompletionProvider.BuildCompletionData
(ICompletionDataGenerator dataGen, IEditorData editor,
System.String EnteredText) [0x0] in :0
at
MonoDevelop.D.Completion.DCodeCompletionSupport.BuildCompletionData
(MonoDevelop.Ide.Gui.Document EditorDocument, IAbstractSyntaxTree
SyntaxTree, MonoDevelop.Ide.CodeCompletion.CodeCompletionContext
ctx, MonoDevelop.Ide.CodeCompletion.CompletionDataList l, Char
triggerChar) [0x0] in :0
at
MonoDevelop.D.DEditorCompletionExtension.HandleCodeCompletion
(MonoDevelop.Ide.CodeCompletion.CodeCompletionContext
completionContext, Char triggerChar, System.Int32&
triggerWordLength) [0x0] in :0
at
MonoDevelop.Ide.Gui.Content.CompletionTextEditorExtension.KeyPress
(Key key, Char keyChar, ModifierType modifier) [0x000f0] in
/Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Content/CompletionTextEditorExtension.cs:126
at MonoDevelop.D.DEditorCompletionExtension.KeyPress (Key key,
Char keyChar, ModifierType modifier) [0x0] in :0
at MonoDevelop.Ide.Gui.Content.TextEditorExtension.KeyPress
(Key key, Char keyChar, ModifierType modifier) [0x00013] in
/Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source
Re: Mono-D v0.4.8
On Tuesday, 15 January 2013 at 21:38:55 UTC, timotheecour wrote: On Tuesday, 15 January 2013 at 21:12:21 UTC, alex wrote: On Saturday, 12 January 2013 at 14:28:46 UTC, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex Got to bump myself up again. Released a new version - this time with improved code indentation. when upgrading to 0.4.8 i get the error below. Then monodevelop crashes and quits. so it is now unusable. Also, can you describe what you mean by "with improved code indentation" ? is that code formatting? I've been long hoping for this! Thanks! An error has occurred Error while updating status of command: MonoDevelop.Ide.Commands.ProjectCommands.Run System.MissingMethodException: Method not found: 'MonoDevelop.Projects.ProjectConfiguration.get_ParentItem'. Awesome, again these problems - which MD version do you've got installed? 3.0.6 stable? Then please switch to the mono-d.alexanderbothe.com/stableMD repository 3.1.0 beta? Then switch to the mono-d.alexanderbothe.com repo. If you're having a Mac system and try to use 3.1.1, please "downgrade" to 3.0.6 stable in order to use the /stableMD repository. I promise, everything will work fine then - I've tested it on Win7 and Mint 13 x86 - It's been launched flawlessly there. With code indent I'm not meaning code formatting but the automated indentation generation after e.g. you've pressed and it inserts 3 tabs because you're in a method of a class of an other class. @Fil: I haven't changed anything regarding GDB support (yet). I'm sorry but I get myself desperate too about what the guys from MD tend to do sometimes. ;) -- What is linux-vdso.so.1 ?
Wed night meeting for Seattle D-heads
A small group of us like to meet once a month for the NWCPP meetings at Microsoft, and then we go out for beers and argue about D, programming, movies, and any other idiot things that come to mind. I suspect that there may be a few of you in the area who may not know about this, so feel free to join in. Welcome to 2013!! I would like to welcome Jeff Tucker as our presenter for the January meeting. Pizza is being provided by Randstad Technologies. Time and Location: January 16, 2013, Microsoft Campus building 40 Steptoe. PLEASE NOTE THIS IS NOT OUR NORMAL MEETING ROOM!!! The presentation will start at 7:00 PM. Title: Metadata and reflection in C++ Abstract: A robust reflection/metadata system in C++ can be extremely powerful and has many applications, particularly in game programming. It can facilitate sophisticated debug output and logging, trivial factory implementation, automatic serialization and deserialization for any arbitrary object, automatic binding to a GUI system, and even automatic binding of objects and function to a scripting language (both Lua and Python are popular). The typeinfo/RTTI system currently in C++ however is simply not up to this level of functionality, so a more sophisticated solution is necessary. In this talk, I will implement a simple, yet powerful, meta reflection system in C++, completely from scratch, and using test-driven development. I will also show how I leverage a similar system in my own game engine. Finally, I promise there will be no more than three PowerPoint slides. Bio: Jeff Tucker is a lecturer of Computer Science at DigiPen Institute of Technology, where he teaches classes on networking, databases, programming, and software engineering. He has been a software engineer for the past 13 years and formerly worked at Microsoft on the Windows Core Networking team. He also currently does research in procedural content generation and graphics algorithms as well as making computer games. Thanks, Lloyd
Re: Mono-D v0.4.8
Nice work, Alex, but something broke my GDB debugger support... :-\ I'm not sure if it's something specific to Arch Linux or not, so can anyone confirm that their Mono-D is work with GDB fine? Mine reports: warning: Could not load shared library symbols for linux-vdso.so.1.\nDo you need \"set solib-search-path\" or \"set sysroot\ [Thread debugging using libthread_db enabled] Using host libthread_db library \"/usr/lib/libthread_db.so.1\".
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 10:22:20 UTC, Chris wrote: A language such as C++ seems like a bad fit for a scripting language because of it's complexity and the difficultly with parsing through it. Also a scripted language probably should not have low level access that is provided by languages such as D and C/C++. --rt Why not? In my experience small scripts often turn into bigger programs and sooner or later you need some sort of low level features. Then you have to write modules in C/C++ and use Swig or something to integrate them. That's why I prefer D, because you can get the whole shebang _if necessary_. There are also copyright issues. If you deliver a Python program, anyone could rip it, even if you compile it to byte code. If you distribute native executables, it's harder to rip your program. In general, I find scripting languages less useful for projects that (might) develop into something bigger. Now that I come to think of it, scripting languages are inherently "quick and dirty", that's why they are not really scalable (think of the class system in Python and Lua, not the real deal). For many applications where a scripted language really shines, there are usually security related issues that require placing strict limitations on what the scripts are allowed to do. You have to understand that the scripts tend to be implemented by the users of the system, rather than just the original developers. Also code may be transmitted from one machine to another and executed, so you have to be careful that malicious code cannot do much harm. I agree with your comment about larger projects that are scripted. I think you'll tend to use large applications like that in environments where the scripting provides little to no advantages, and it becomes mostly a disadvantage in terms of eating up resources for no good reason. I can see an advantage for the developers, but the users of the application tends to suffer, so if the application could later be compiled to native machine code for distribution, that would close the gap. --rt
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 20:02:58 UTC, Walter Bright wrote: On 1/14/2013 10:30 PM, Rob T wrote: A really important advantage that scripting languages provides that D does not currently provide, is direct runtime interpretation of the language. This is very important for the use cases of script languages such as Ruby and PHP, because often they are used for coding and testing on the fly, ie., used in an environment that requires frequent changes with almost instant feedback. The way this is currently done is to put the code that would otherwise be in a script into a DLL, and then the dev process becomes: 1. run program 2. dynamically load DLL with "script" 3. debug 4. change "script" code 5. recompile "script" into new DLL 6. reload DLL 7. rinse, repeat It turns out that step 5 is nearly instant, on the order of a few seconds. Doing that is still more difficult in terms of technical skills. Also even when you have the skills, you need more access to perform code modifications remotely. Often too, you do not want to take down the entire application to make a quick fix to some bad code. I think fully scripted languages appeal to the less technically inclined who prefer to "just get it done" with the least amount of hassle. I'll suggest that the gap can be filled between scripted and compiled in a way that may get some serious attention. The rapid development process of a scripted language loses its advantage the minute the code stabilizes because at the point of stability, the interpretation process becomes a burden on resources without any advantages. If the stable scripted code can be compiled and linked in, then it gains the advantages of a compiled language. This is an important point, because companies with large server farms are aware that they are paying far more money for processing power than they need to because their servers are running scripted code most of the time. For example, Twitter moved from Ruby to Java to gain performance, so imagine what they could get if they moved to something like D instead. The hair in the process, however, is DLLs still need better support in D. Yes, having full DLL support will help, and I cannot wait for that support. When we say "DLL" that usually means Microsoft's implementation of dynamic linking, but we need support for Linux too. Also please do not overlook the importance of dynamically loaded libraries (loaded during runtime) for implementing loadable plugins giving you extensibility options like what you see with Firefox and other popular applications. Once D has plugin support, I'll be very happy. You can also embed a scripting language directly into other applications, and store "code" as data, which can be transmitted from one machine to another over the wire. We can store and transmit D code too, but getting it to automatically run on the other end is not so easy or convenient. Just so you know, we have a Javascript engine written in D, meaning you can embed Javascript. I knew about it, but I read somewhere that it was not fully compatible with the version of JS that is being used for web related work, is this correct? Still, it can be useful to have a look at it to see how it does its job. I wonder if the work on the CTFE can be somehow spun off into an embeddable D interpreter? --rt
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 20:07:49 UTC, Walter Bright wrote: On 1/15/2013 8:37 AM, Paulo Pinto wrote: Then I started working in multi-site projects with developers from all types of backgrounds, and understood the value of a consistent project code formatting. I agree with the value as you say, but as I posted previously I think consistent formatting is the job of a source code formatter, not the language. Sure, I was speaking in general. Even better, have some kind of indent tool run as part of the check-in process.
Re: cgdb 0.6.7 release - with D syntax highlight support.
On 15 January 2013 22:09, timotheecour wrote: > Could you please provide some more information for usage / installation? > > on osx I was able to install it with: > brew install readline > ./configure --with-readline=/usr/local/**homebrew/Cellar/readline/6.2.4 > > 1) however, running a simple hello world with rdmd --build-only -g main > and then cgdb ./main doesn't seem to show any debugging symbols (line > numbers etc). Is that because of the issue with the extra underscore > produced in D mangling on OSX? > > Which compiler are you using, dmd's? I'm not sure how good dmd emits debugging symbols on OSX, you could try using -gc switch instead of -g. Raise a bug with the revelant compiler. 2) > on ubuntu, I can't get it to install: > ./configure --with-readline=/some_path/**libreadline.a > however it complains about ncurses not found, even with options such as: > --with-ncurses=/some_path/**libncurses.so > > I just built mine with: ./configure --prefix=/usr You should only require the following installed: autotools-dev, libncurses5-dev, libreadline6-dev Regards, Iain. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: cgdb 0.6.7 release - with D syntax highlight support.
Could you please provide some more information for usage / installation? on osx I was able to install it with: brew install readline ./configure --with-readline=/usr/local/homebrew/Cellar/readline/6.2.4 1) however, running a simple hello world with rdmd --build-only -g main and then cgdb ./main doesn't seem to show any debugging symbols (line numbers etc). Is that because of the issue with the extra underscore produced in D mangling on OSX? 2) on ubuntu, I can't get it to install: ./configure --with-readline=/some_path/libreadline.a however it complains about ncurses not found, even with options such as: --with-ncurses=/some_path/libncurses.so On Monday, 14 January 2013 at 12:07:21 UTC, Iain Buclaw wrote: A new release of cgdb has been made today. https://raw.github.com/cgdb/cgdb/v0.6.7/NEWS This includes the new feature of syntax highlight support for D applications. http://s1.postimage.org/yek8rlpy5/Screenshot_from_2013_01_14_11_58_40.png Sources are obtainable from here: http://cgdb.me/files/cgdb-0.6.7.tar.gz Expect binary releases to become available in your next distribution release! If anyone finds any bugs, do let me know. Thanks, Iain.
Re: Mono-D v0.4.8
On Tuesday, 15 January 2013 at 21:12:21 UTC, alex wrote: On Saturday, 12 January 2013 at 14:28:46 UTC, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex Got to bump myself up again. Released a new version - this time with improved code indentation. when upgrading to 0.4.8 i get the error below. Then monodevelop crashes and quits. so it is now unusable. Also, can you describe what you mean by "with improved code indentation" ? is that code formatting? I've been long hoping for this! Thanks! An error has occurred Error while updating status of command: MonoDevelop.Ide.Commands.ProjectCommands.Run System.MissingMethodException: Method not found: 'MonoDevelop.Projects.ProjectConfiguration.get_ParentItem'. at MonoDevelop.D.DProjectConfiguration.UpdateGlobalVersionIdentifiers (MonoDevelop.D.DProject prjOverride) [0x0] in :0 at MonoDevelop.D.DProject..ctor (MonoDevelop.Projects.ProjectCreateInformation info, System.Xml.XmlElement projectOptions) [0x0] in :0 at MonoDevelop.D.DProjectBinding.CreateProject (MonoDevelop.Projects.ProjectCreateInformation info, System.Xml.XmlElement projectOptions) [0x0] in :0 at MonoDevelop.D.DProjectBinding.CreateSingleFileProject (System.String sourceFile) [0x0] in :0 at MonoDevelop.Projects.ProjectService.CreateSingleFileProject (System.String file) [0x0002e] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Core/MonoDevelop.Projects/ProjectService.cs:488 at MonoDevelop.Ide.ProjectOperations.CanExecuteFile (System.String file, MonoDevelop.Projects.ExecutionContext context) [0x0] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/ProjectOperations.cs:1007 at MonoDevelop.Ide.ProjectOperations.CanExecuteFile (System.String file, IExecutionHandler handler) [0x00011] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/ProjectOperations.cs:1002 at MonoDevelop.Ide.Gui.Document.CanRun (IExecutionHandler handler) [0x0] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Document.cs:446 at MonoDevelop.Ide.Commands.RunHandler.CanRun (IExecutionHandler executionHandler) [0x00037] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Commands/ProjectCommands.cs:270 at MonoDevelop.Ide.Commands.RunHandler.Update (MonoDevelop.Components.Commands.CommandInfo info) [0x00048] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Commands/ProjectCommands.cs:262 at MonoDevelop.Components.Commands.CommandHandler.InternalUpdate (MonoDevelop.Components.Commands.CommandInfo info) [0x0] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandHandler.cs:47 at MonoDevelop.Components.Commands.CommandManager.DefaultUpdateCommandInfo (MonoDevelop.Components.Commands.ActionCommand cmd, MonoDevelop.Components.Commands.CommandInfo info) [0x00079] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandManager.cs:1257 at MonoDevelop.Components.Commands.CommandManager.GetCommandInfo (System.Object commandId, MonoDevelop.Components.Commands.CommandTargetRoute targetRoute) [0x001a9] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-3.0-series/90a53d19/source/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandManager.cs:1223
Re: Mono-D v0.4.8
On Saturday, 12 January 2013 at 14:28:46 UTC, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com Cheers, Alex Got to bump myself up again. Released a new version - this time with improved code indentation.
Re: A look at the D programming language by Ferdynand Górski
class: def: for: if: You could call it "south west" code. Recte: South east code, of course! Then I started working in multi-site projects with developers from all types of backgrounds, and understood the value of a consistent project code formatting. -- Paulo In most languages, there are coding conventions, and projects should have consistent formatting. I agree. However, I think indentation as part of the syntax is highly exaggerated. A language can and should protect programmers from making stupid or common mistakes and offer features that make programming more efficient and software more reliable. To enforce a certain aesthetic style, based on personal preferences more often than not, should not be part of the language, but up to the teams that use the language. On top of that, Python code can be messy too (although it might look "nice"). In _my_ experience, readability is often impeded by the use of obscure variable and function names. v = r.calc(m.get_p() / m.get_r()) What is "v", what is calc() calculating ...? Such code can be due to laziness or arrogance. But no language feature can prevent bad or lazy programmers from producing such code, even if it's nicely formatted. Anyway, 1,000 programmers will have 1,001 views on coding style.
Re: A look at the D programming language by Ferdynand Górski
On 1/15/2013 4:09 AM, bearophile wrote: One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability). This is the job of a syntax aware editor (and other source code formatting tools), not the language. In my not-so-humble opinion. BTW, I'd like to see a source code formatter for D. Anyone want to step up?
Re: A look at the D programming language by Ferdynand Górski
On 1/15/2013 8:37 AM, Paulo Pinto wrote: Then I started working in multi-site projects with developers from all types of backgrounds, and understood the value of a consistent project code formatting. I agree with the value as you say, but as I posted previously I think consistent formatting is the job of a source code formatter, not the language.
Re: A look at the D programming language by Ferdynand Górski
On 1/14/2013 10:30 PM, Rob T wrote: A really important advantage that scripting languages provides that D does not currently provide, is direct runtime interpretation of the language. This is very important for the use cases of script languages such as Ruby and PHP, because often they are used for coding and testing on the fly, ie., used in an environment that requires frequent changes with almost instant feedback. The way this is currently done is to put the code that would otherwise be in a script into a DLL, and then the dev process becomes: 1. run program 2. dynamically load DLL with "script" 3. debug 4. change "script" code 5. recompile "script" into new DLL 6. reload DLL 7. rinse, repeat It turns out that step 5 is nearly instant, on the order of a few seconds. The hair in the process, however, is DLLs still need better support in D. You can also embed a scripting language directly into other applications, and store "code" as data, which can be transmitted from one machine to another over the wire. We can store and transmit D code too, but getting it to automatically run on the other end is not so easy or convenient. Just so you know, we have a Javascript engine written in D, meaning you can embed Javascript.
Re: DPaste ain't going anywhere
On 2013-01-15, 20:29, Jesse Phillips wrote: On Monday, 14 January 2013 at 09:34:50 UTC, nazriel wrote: Hello! I would love to say that it was just 1 April joke that Dpaste is going down but I can't. Things got complicated. I couldn't afford extending domain because I began to run low on money. Just a thought paste.dlang.org? Yes please. -- Simen
[OT] Re: DPaste ain't going anywhere
On Mon, 14 Jan 2013 10:34:48 +0100 "nazriel" wrote: > > Thanks to Vladimir Panteleev aka CyberShadow, who donated money > in order to extended domain. Things need a bit of time in order > to make everything work, of course banks being the biggest > bottleneck as usually. For those who can't live without Dpaste > anymore, Vladimir created temporary subdomain. Here it is: > Sounds great! Thanks Vladimir! > The most important things seems to work well. The only problem > for now maybe loging in with Github, Google, and Facebook > accounts. This issue will be resolved soon. Do you have any good info on using those to do logins? Is it all just simply OpenID, or are they custom APIs? That's something I was going to need to look into anyway. (Yea, everyone knows I hate those things, but I realize not everyone feels the same, so it can be a value-add feature.)
Re: DPaste ain't going anywhere
On Monday, 14 January 2013 at 09:34:50 UTC, nazriel wrote: Hello! I would love to say that it was just 1 April joke that Dpaste is going down but I can't. Things got complicated. I couldn't afford extending domain because I began to run low on money. Just a thought paste.dlang.org?
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 13:43:12 UTC, Chris wrote: On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote: Chris: Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length). It happens very quickly if you have a class, a def, a nested for loop with one or two if statements class: def: for: if: You could call it "south west" code. Curiously the Python significant syntax was the motive for me to start using Python in the first place, years ago. I was looking right for that, being fed up of begin-end, curly braces, and those code reading mistakes I was talking about. Bye, bearophile It's simply not my style. I don't believe indentation should be a rule. I clean up my code in my own way. I used to think like that a few decades ago. Then I started working in multi-site projects with developers from all types of backgrounds, and understood the value of a consistent project code formatting. -- Paulo
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote: Chris: Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length). It happens very quickly if you have a class, a def, a nested for loop with one or two if statements class: def: for: if: You could call it "south west" code. Curiously the Python significant syntax was the motive for me to start using Python in the first place, years ago. I was looking right for that, being fed up of begin-end, curly braces, and those code reading mistakes I was talking about. Bye, bearophile It's simply not my style. I don't believe indentation should be a rule. I clean up my code in my own way.
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 12:36:42 UTC, bearophile wrote: Chris: Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length). and the fact that one missing white space (a typo after deleting a line) screws up the whole script is just annoying. It's a small price to pay for increased code readability. And if I see one missing white space in D code, I fix it right now, so there is not a lot of difference. The Python indentation terror is a peculiar personal preference enshrined in the language's syntax. It's simply not my style. Curiously the Python significant syntax was the motive for me to start using Python in the first place, years ago. I was looking right for that, being fed up of begin-end, curly braces, and those code reading mistakes I was talking about. Bye, bearophile Although Python gets bashed a lot due to this issue, it is not the only language doing that. Haskell, OCaml and F# have similar rules.
Re: A look at the D programming language by Ferdynand Górski
Chris: Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are If you use the standard 4 spaces indentations and you don't have ten indentation levels this problem is not common. Some persons also avoid your problem with an editor that shows thin vertical lines every 4 spaces (but only where the lines are actually reaching that length). and the fact that one missing white space (a typo after deleting a line) screws up the whole script is just annoying. It's a small price to pay for increased code readability. And if I see one missing white space in D code, I fix it right now, so there is not a lot of difference. The Python indentation terror is a peculiar personal preference enshrined in the language's syntax. It's simply not my style. Curiously the Python significant syntax was the motive for me to start using Python in the first place, years ago. I was looking right for that, being fed up of begin-end, curly braces, and those code reading mistakes I was talking about. Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
> That's not my experience. Nested for loops with if-statements can be > hard on the eye in Python, because you have to go back an double check > on which level you actually are and the fact that one missing white > space (a typo after deleting a line) screws up the whole script is just > annoying. The Python indentation terror is a peculiar personal > preference enshrined in the language's syntax. It's simply not my style. > If you use notepad to write your Python Code yes. If you see yourself too many indentation levels, that's a good indicator you're writing bad code (bad is the wrong term, but can't think of the correct english word).
Re: A look at the D programming language by Ferdynand Górski
Am 15.01.2013 13:23, schrieb David: >> That's not my experience. Nested for loops with if-statements can be >> hard on the eye in Python, because you have to go back an double check >> on which level you actually are and the fact that one missing white >> space (a typo after deleting a line) screws up the whole script is just >> annoying. The Python indentation terror is a peculiar personal >> preference enshrined in the language's syntax. It's simply not my style. >> > > If you use notepad to write your Python Code yes. If you see yourself > too many indentation levels, that's a good indicator you're writing bad > code (bad is the wrong term, but can't think of the correct english word). > I think we are getting into a language flame, we should probably stop here. I love Pythons indentation because of various reasons, you don't like them.
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 12:09:21 UTC, bearophile wrote: 1100110: Thats so funny I forgot to laugh. One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability). Bye, bearophile That's not my experience. Nested for loops with if-statements can be hard on the eye in Python, because you have to go back an double check on which level you actually are and the fact that one missing white space (a typo after deleting a line) screws up the whole script is just annoying. The Python indentation terror is a peculiar personal preference enshrined in the language's syntax. It's simply not my style.
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 11:43:58 UTC, David wrote: Stereotypes of people who never actually used it, other than tried it and gave up because they didn't configure their editor correctly and blaming python for it. I bet my last indentation error was more than two years ago. Not a stereotype, sorry to disappoint you, I have used Python quite a lot in my job (and still do). My point is, as soon as you have to use a specialized editor and configure the editor to format Python properly, there is something wrong, in my opinion. A language shouldn't depend on indentation. Indentation is just a means to an end (=readability) but not an end in itself. To make it part of the syntax is over the top, if not neurotic. Everyone in his or her right mind will use some kind of formatting anyway and avoid spaghetti code. No need to enforce it. It should be up to the programmer / team how to do this. But this is not a Python forum, and I am quite happy with the C-style D offers.
Re: A look at the D programming language by Ferdynand Górski
1100110: Thats so funny I forgot to laugh. One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability). Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
On 01/15/2013 05:00 AM, bearophile wrote: Chris: or indentation (t)errors (Python) In practice Python usually decreases the number of indentation-related bugs, Thats so funny I forgot to laugh.
Re: A look at the D programming language by Ferdynand Górski
> Maybe it does, but it's annoying while you are writing it, and to be > honest, indentation bugs are far and few between, in my experience, if > you use the curly braces consistently. Only you have more freedom. What > I was referring to was the annoying Python message "Wrong indentation in > line ...", when you run a script, which makes it hard to copy & paste > and just test a snippet, before you integrate it properly. Well, that's > me. Other people like rules and regulations. > Stereotypes of people who never actually used it, other than tried it and gave up because they didn't configure their editor correctly and blaming python for it. I bet my last indentation error was more than two years ago.
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 11:00:29 UTC, bearophile wrote: Chris: or indentation (t)errors (Python) In practice Python usually decreases the number of indentation-related bugs, even considering the "dangling else" warning we have added to D, because indentation and block nesting are the same thing, it's more DRY :-) Bye, bearophile Maybe it does, but it's annoying while you are writing it, and to be honest, indentation bugs are far and few between, in my experience, if you use the curly braces consistently. Only you have more freedom. What I was referring to was the annoying Python message "Wrong indentation in line ...", when you run a script, which makes it hard to copy & paste and just test a snippet, before you integrate it properly. Well, that's me. Other people like rules and regulations.
Re: A look at the D programming language by Ferdynand Górski
Chris: or indentation (t)errors (Python) In practice Python usually decreases the number of indentation-related bugs, even considering the "dangling else" warning we have added to D, because indentation and block nesting are the same thing, it's more DRY :-) Bye, bearophile
Re: A look at the D programming language by Ferdynand Górski
On Tuesday, 15 January 2013 at 06:30:33 UTC, Rob T wrote: A really important advantage that scripting languages provides that D does not currently provide, is direct runtime interpretation of the language. This is very important for the use cases of script languages such as Ruby and PHP, because often they are used for coding and testing on the fly, ie., used in an environment that requires frequent changes with almost instant feedback. This is true. On the other hand, if you do quick and dirty stuff (count the frequency of certain words, parse data files etc.), the compilation time is not really an issue, and due to unnecessarily ugly syntax (PHP, Perl) or indentation (t)errors (Python) you sometimes lose time, or cannot just copy and paste snippets to test them without checking your spaces. [...] A language such as C++ seems like a bad fit for a scripting language because of it's complexity and the difficultly with parsing through it. Also a scripted language probably should not have low level access that is provided by languages such as D and C/C++. --rt Why not? In my experience small scripts often turn into bigger programs and sooner or later you need some sort of low level features. Then you have to write modules in C/C++ and use Swig or something to integrate them. That's why I prefer D, because you can get the whole shebang _if necessary_. There are also copyright issues. If you deliver a Python program, anyone could rip it, even if you compile it to byte code. If you distribute native executables, it's harder to rip your program. In general, I find scripting languages less useful for projects that (might) develop into something bigger. Now that I come to think of it, scripting languages are inherently "quick and dirty", that's why they are not really scalable (think of the class system in Python and Lua, not the real deal).
