Re: DConf 2014 Call for Submissions is now open
On Wednesday, 27 November 2013 at 14:37:11 UTC, Dicebot wrote: On Wednesday, 27 November 2013 at 05:44:36 UTC, Jonathan M Davis wrote: And now I have to wrack my brain for ideas. :) I could probably answer questions about D all day, but coming up with something useful to talk about on my own never seems to be as easy as it should be... I had some until I have started to think about Credentials: What qualifies you to talk on the topic of choice?. Have honestly answered Nothing and closed the page. :) Will try my best to get there as a visitor this time though. Wrong way of thinking, IMHO - most people who do talks on conferences are not the superexperts on some field... Furthermore, sometimes people are less qualified do better talks as they focus more on presenting something to the audience. So you do not have to be superqualified, but you have to: 1) like the thing you are presenting 2) be good at presenting Cheers!
DUB 0.9.20
A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: - Builds are now cached and only rebuilt when necessary for dub build and dub run. - Generated VisualD projects and the output of dub describe now contain import files and string import files in addition to pure source files. - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. - Pre-release versions of dependencies (e.g. 1.0.0-rc.1) are now only installed of nothing else matches the version expression, or if dub upgrade --prerelease is used. This is supposed to encourage the use of pre-release versions instead of just working with branches for released packages. - https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md We also have now well over a hundred packages in the registry, 117 at this point [1]! Download at http://code.dlang.org/download In the works for the next version is, among other things, a dub test [2] command which executes unit tests (and possibly other kinds of tests later) using a custom main() function, especially useful for automated testing and testing of libraries without a main() function. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub/issues/83
Re: vibe.d 0.7.18 has been released
On 2013-11-26 19:31:44 +, Sönke Ludwig said: Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d Out of curiosity, it looks like vibe.d could be used to implement all kind of network protocolls. Is that right? Or is this use-case to screwed-up for it? -- Robert M. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: vibe.d 0.7.18 has been released
Anything stream orientated. I didn't see a udp stream though that sounds useful. On 29 Nov 2013 19:35, Robert M. Münch robert.mue...@saphirion.com wrote: On 2013-11-26 19:31:44 +, Sönke Ludwig said: Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d Out of curiosity, it looks like vibe.d could be used to implement all kind of network protocolls. Is that right? Or is this use-case to screwed-up for it? -- Robert M. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: vibe.d 0.7.18 has been released
Am 29.11.2013 18:54, schrieb Rory McGuire: Anything stream orientated. I didn't see a udp stream though that sounds useful. http://vibed.org/api/vibe.core.net/listenUDP It's currently limited to TCP and UDP, but adding other protocols when required is simple.
Re: DUB 0.9.20
New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ -- Jordi Sayol
Re: vibe.d 0.7.18 has been released
On 29 Nov 2013 20:25, Sönke Ludwig slud...@outerproduct.org wrote: http://vibed.org/api/vibe.core.net/listenUDP It's currently limited to TCP and UDP, but adding other protocols when required is simple. Ooo could one write a Dns server with it?
Re: DUB 0.9.20
On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages.
Re: DUB 0.9.20
El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. Different case is dmd and development packages -dev. Debian packaging system do not allow to install multiple versions of the same package at same time. i.e. dmd_2.064.2-0_amd64.deb is newer version of dmd_2.063.2-0_amd64.deb, and upgrades it. same with libphobos2-dev_2.064.2_amd64.deb, which replaces libphobos2-dev_2.063.2_amd64.deb by an upgrade. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Regards, -- Jordi Sayol
Re: DUB 0.9.20
On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote: El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. OK, I see. Can we have different DMD packages with different DMD names? For example, can we have `dmd-63` and `dmd-64` at the same time? So, the `dmd` is simple alias to the latest DMD version. Sorry if I miss something, but it looks like possible solution. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Yes, I know. But packages save some time.
Re: DUB 0.9.20
On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote: - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. Why would that be desirable? I would expect a set of HTML files if generating documentation, and if a server is required to read the documentation instead of just bringing them up in your browser, that's a major usability problem IMHO. If ddox requires a server rather than just working with .html files, that would be a big reason for me to never use it. - Jonathan M Davis
Re: DUB 0.9.20
El 29/11/13 21:54, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote: El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. OK, I see. Can we have different DMD packages with different DMD names? For example, can we have `dmd-63` and `dmd-64` at the same time? So, the `dmd` is simple alias to the latest DMD version. Sorry if I miss something, but it looks like possible solution. Is not the target of this repository. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Yes, I know. But packages save some time. -- Jordi Sayol
Re: DUB 0.9.20
Am 29.11.2013 21:27, schrieb Shammah Chancellor: On 2013-11-29 17:01:53 +, Sönke Ludwig said: - Builds are now cached and only rebuilt when necessary for dub build and dub run. Doesn't seem to be working correctly for me. Won't rebuild after a build failure. Hm... there may be an issue when the linker fails, but leaves a partially linked binary. I'll add some manual code that deletes the result after the linker returns with an error.
Re: vibe.d 0.7.18 has been released
Am 29.11.2013 20:28, schrieb Rory McGuire: On 29 Nov 2013 20:25, Sönke Ludwig slud...@outerproduct.org mailto:slud...@outerproduct.org wrote: http://vibed.org/api/vibe.core.net/listenUDP It's currently limited to TCP and UDP, but adding other protocols when required is simple. Ooo could one write a Dns server with it? Should be no problem.
Re: DUB 0.9.20
Am 29.11.2013 23:05, schrieb Jonathan M Davis: On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote: - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. Why would that be desirable? I would expect a set of HTML files if generating documentation, and if a server is required to read the documentation instead of just bringing them up in your browser, that's a major usability problem IMHO. If ddox requires a server rather than just working with .html files, that would be a big reason for me to never use it. - Jonathan M Davis You can still use dub build --build=ddox to generate actual HTML files, but using run it will simply skip the generation part and displays the documentation much faster, depending on the size of the project.
Re: DUB 0.9.20
Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option?
Re: DUB 0.9.20
El 30/11/13 02:08, Piotr Szturmaj ha escrit: Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option? $ dub help prints version on last line: DUB version v0.9.20 -- Jordi Sayol
Re: DUB 0.9.20
On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote: On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote: - Builds are now cached and only rebuilt when necessary for dub build and dub run. When I build a vibe project, and edit the app.d and then build again, an error occurs: - Checking dependencies in '/media/sf_github/dsp' Error: Orphan format specifier: %File '%s' was modified in the future. Please re-save. - Sorry, this seems to be caused by a time problem in my share folder. please ignore it. But after I do a `ls` command (or other commands) and then `dub` again, it went ok again. Another thing to note is when app.d is modified, dub recompiles all the *.dt files, is that the case? Does dub support increment compiling?
Re: DUB 0.9.20
Am 30.11.2013 03:21, schrieb Puming: On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote: On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote: - Builds are now cached and only rebuilt when necessary for dub build and dub run. When I build a vibe project, and edit the app.d and then build again, an error occurs: - Checking dependencies in '/media/sf_github/dsp' Error: Orphan format specifier: %File '%s' was modified in the future. Please re-save. - Sorry, this seems to be caused by a time problem in my share folder. please ignore it. I've fixed the log message though, so it should read now just File '...' was modified in the future. Please re-save. But after I do a `ls` command (or other commands) and then `dub` again, it went ok again. Another thing to note is when app.d is modified, dub recompiles all the *.dt files, is that the case? Does dub support increment compiling? This is planned, but (AFAIK) this is not yet possible in an optimal way due to how DMD emits symbols to object files. Currently the only reliable way to build incrementally is to compile a single file at a time, but this is very inefficient compared to compiling multiple files in one go. A middle ground, which will be added in one of the next versions, is to build and cache each dependency as a separate static library. But this will still always build each complete package in one go, so all templates as well.
Re: DUB 0.9.20
On 2013-11-29 22:39:33 +, Sönke Ludwig said: Am 29.11.2013 21:27, schrieb Shammah Chancellor: On 2013-11-29 17:01:53 +, Sönke Ludwig said: - Builds are now cached and only rebuilt when necessary for dub build and dub run. Doesn't seem to be working correctly for me. Won't rebuild after a build failure. Hm... there may be an issue when the linker fails, but leaves a partially linked binary. I'll add some manual code that deletes the result after the linker returns with an error. I'll post an issue when I can isolate why it was doing it. I can't seem to reproduce it now, but it was definitely doing it earlier.It kept rerunning old binaries on me untill I made superfulous changes to files and re-saved.
Re: DUB 0.9.20
On 2013-11-30 02:58:50 +, Sönke Ludwig said: This is planned, but (AFAIK) this is not yet possible in an optimal way due to how DMD emits symbols to object files. Currently the only reliable way to build incrementally is to compile a single file at a time, but this is very inefficient compared to compiling multiple files in one go. Can you even do this when templated symbols are defined in that file? This was horribly broken years ago as the templated symbols were emitted into the source file that the template was in, rather than the including file.
Re: D vs Go in real life
On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please create a paste with the two code
samples?
Thanks,
Andrei
Hello,
here is the Go code:
package main
import (
fmt
)
type Point struct {
x, y int
}
type Rectangular struct {
topLeft, bottomRight Point
}
func (self Rectangular) Left() int {
return self.topLeft.x
}
func (self Rectangular) Right() int {
return self.bottomRight.x
}
func (self Rectangular) Width() int {
return self.Right() - self.Left()
}
type Rectangle struct {
Rectangular
}
func NewRectangle(topLeft, bottomRight Point) *Rectangle {
rectangle := new(Rectangle)
rectangle.Rectangular.topLeft = topLeft
rectangle.Rectangular.bottomRight = bottomRight
return rectangle
}
func main() {
rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
fmt.Println(rectangle.Width())
}
And this is the Scala code:
import java.awt.Point
trait Rectangular {
protected val topLeft: Point
protected val bottomRight: Point
def width : Int = bottomRight.x - topLeft.x
}
class Rectangle(val topLeft: Point, val bottomRight: Point)
extends Rectangular
object RunIt extends Application {
val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
println(rectangle.width)
}
I guess in D you would do something like this:
mixin template Rectangular() {
Point x, y;
}
mixin Rectangular;
struct Rectangle {
mixin Rectangular;
}
Note that in the Scala code Rectangular.topLeft and
Rectangular.bottomRight are protected. Since the solution in Go
makes use of delegation this can only be accomplished in Go
through making getters public or defining Rectangle in the same
package as Rectangular. Since Go does not have constructors the
way to initialize a Rectangle in Go looks more clumsy.
An interesting point to me is that Rectangular in Go is just an
ordinary struct whereas Rectangular is a special construct in
Scala (being a trait) and in D (being a mixin). So Scala and D
force you to design ahead, e.g. you have to decide in advance
whether to make Rectangular a trait or mixin. Thereafter,
Rectangular is not of use on its own, only when used as a trait
or mixin.
What makes me think is whether delegation as a language construct
has been underrated and whether Go now makes this obvious.
-- Bienlein
Re: Optlink and Avast
On Friday, 29 November 2013 at 03:58:59 UTC, Rikki Cattermole wrote: Has anyone else hit with Avast recognising Optlink as a suspicious file since last update? The same issue. I added dmd folder to trusted list.
Re: D vs Go in real life
On Thursday, 28 November 2013 at 19:25:56 UTC, Dicebot wrote: On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote: ... -- Bienlein IMHO, problem with go simplicity is not as much as being not expressive enough to do something as with being forced to move lot of things to run-time. Could you just quickly describe what you mean by being forced to move lot of things to run-time? I simply don't see what you are refering to. Thanks.
Re: What is the current point to empty/null associative arrays?
On Friday, 29 November 2013 at 08:32:12 UTC, Cooler wrote:
...
Try making fill array look more like this:
void fillArray(ref string[int] a) { a[10] = A; }
The issue is that an array (and/or associative array) is a value
type. Basically, you can look at it as a struct with a pointer
(and some extra info). If you don't pass it as a ref then
reallocations (such as what happens when you add an item to an
empty AA) will cause the two to not point to the same information
anymore.
Re: std.complex
On 29/11/13 08:50, Iain Buclaw wrote: That repo doesn't seem to exist (must by my imagination). It's just the branch imaginary in my regular Phobos repo (I always use feature branches for new stuff). The link works for me, what goes wrong for you?
Re: What is the current point to empty/null associative arrays?
On Friday, 29 November 2013 at 08:48:03 UTC, Chris Cain wrote:
On Friday, 29 November 2013 at 08:32:12 UTC, Cooler wrote:
...
Try making fill array look more like this:
void fillArray(ref string[int] a) { a[10] = A; }
The issue is that an array (and/or associative array) is a
value type. Basically, you can look at it as a struct with a
pointer (and some extra info). If you don't pass it as a ref
then reallocations (such as what happens when you add an item
to an empty AA) will cause the two to not point to the same
information anymore.
But on the other hand, AA array is sometimes affected without ref
parameter, so advice to put ref does not explain per se the issue.
Actually this is a good defficiency illustration of separation
between value types and 'reference types' which are passed 'by
reference'.
Re: What is the current point to empty/null associative arrays?
On Friday, 29 November 2013 at 09:39:57 UTC, Cooler wrote:
On Friday, 29 November 2013 at 08:48:03 UTC, Chris Cain wrote:
On Friday, 29 November 2013 at 08:32:12 UTC, Cooler wrote:
...
Try making fill array look more like this:
void fillArray(ref string[int] a) { a[10] = A; }
The issue is that an array (and/or associative array) is a
value type. Basically, you can look at it as a struct with a
pointer (and some extra info). If you don't pass it as a ref
then reallocations (such as what happens when you add an item
to an empty AA) will cause the two to not point to the same
information anymore.
Adding ref is not an exit. I show this example only for
simplicity. In my real example I have to fill different AA base
on condition:
string[int] aa1, aa2;
...
auto aaToFill = someCheck ? aa1 : aa2;
// Then do something with aaToFill
If aa1 is empty it will never be filled.
string[int]* aaToFill = someCheck ? aa1 : aa2;
(*aaToFill)[A] = 1;
Re: Is this a bug ?
Adam D. Ruppe: It is perfectly valid to pass a string to the write function. He simply called the wrong function. Sorry. Bye, bearophile
D Programming Language Statistics
hi, D developer could subscribe to ohloh their D project. That is quick and that do always some marketing about dlang. they are no cost to do it link - https://www.ohloh.net/languages/dmd
Re: Unicode handling comparison
On Wednesday, 27 November 2013 at 20:13:32 UTC, Dmitry Olshansky wrote: I could have sworn we had byGrapheme somewhere, well apparently not :( Simple attempt: https://github.com/D-Programming-Language/phobos/pull/1736
Re: Optlink and Avast
On Friday, 29 November 2013 at 08:32:41 UTC, Pavel wrote: On Friday, 29 November 2013 at 03:58:59 UTC, Rikki Cattermole wrote: Has anyone else hit with Avast recognising Optlink as a suspicious file since last update? The same issue. I added dmd folder to trusted list. I'm going to report this to Avast as a false positive since you have confirmed it. I won't send them Optlink because I'm not sure about license issues.
Re: Optlink and Avast
On Friday, 29 November 2013 at 10:50:53 UTC, Rikki Cattermole wrote: On Friday, 29 November 2013 at 08:32:41 UTC, Pavel wrote: On Friday, 29 November 2013 at 03:58:59 UTC, Rikki Cattermole wrote: Has anyone else hit with Avast recognising Optlink as a suspicious file since last update? The same issue. I added dmd folder to trusted list. I'm going to report this to Avast as a false positive since you have confirmed it. I won't send them Optlink because I'm not sure about license issues. Never mind I have to send it to them as by form. Walter can you please confirm that I can do this?
Re: std.complex
On 29 November 2013 11:50, Iain Buclaw ibuc...@gdcproject.org wrote: On 29 November 2013 08:57, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 29/11/13 08:50, Iain Buclaw wrote: That repo doesn't seem to exist (must by my imagination). It's just the branch imaginary in my regular Phobos repo (I always use feature branches for new stuff). The link works for me, what goes wrong for you? Turned out the RJ45 cable in my computer was imaginary. :o) Fixed by switching to real. :-P
Re: std.complex
On 29 November 2013 08:57, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 29/11/13 08:50, Iain Buclaw wrote: That repo doesn't seem to exist (must by my imagination). It's just the branch imaginary in my regular Phobos repo (I always use feature branches for new stuff). The link works for me, what goes wrong for you? Turned out the RJ45 cable in my computer was imaginary. :o)
Re: D vs Go in real life
On Friday, 29 November 2013 at 08:29:04 UTC, Bienlein wrote:
On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please create a paste with the two code
samples?
Thanks,
Andrei
Hello,
here is the Go code:
package main
import (
fmt
)
type Point struct {
x, y int
}
type Rectangular struct {
topLeft, bottomRight Point
}
func (self Rectangular) Left() int {
return self.topLeft.x
}
func (self Rectangular) Right() int {
return self.bottomRight.x
}
func (self Rectangular) Width() int {
return self.Right() - self.Left()
}
type Rectangle struct {
Rectangular
}
func NewRectangle(topLeft, bottomRight Point) *Rectangle {
rectangle := new(Rectangle)
rectangle.Rectangular.topLeft = topLeft
rectangle.Rectangular.bottomRight = bottomRight
return rectangle
}
func main() {
rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
fmt.Println(rectangle.Width())
}
And this is the Scala code:
import java.awt.Point
trait Rectangular {
protected val topLeft: Point
protected val bottomRight: Point
def width : Int = bottomRight.x - topLeft.x
}
class Rectangle(val topLeft: Point, val bottomRight: Point)
extends Rectangular
object RunIt extends Application {
val rectangle = new Rectangle(new Point(1, 2), new Point(12,
2))
println(rectangle.width)
}
I guess in D you would do something like this:
mixin template Rectangular() {
Point x, y;
}
mixin Rectangular;
struct Rectangle {
mixin Rectangular;
}
Note that in the Scala code Rectangular.topLeft and
Rectangular.bottomRight are protected. Since the solution in Go
makes use of delegation this can only be accomplished in Go
through making getters public or defining Rectangle in the same
package as Rectangular. Since Go does not have constructors the
way to initialize a Rectangle in Go looks more clumsy.
An interesting point to me is that Rectangular in Go is just an
ordinary struct whereas Rectangular is a special construct in
Scala (being a trait) and in D (being a mixin). So Scala and D
force you to design ahead, e.g. you have to decide in advance
whether to make Rectangular a trait or mixin. Thereafter,
Rectangular is not of use on its own, only when used as a trait
or mixin.
What makes me think is whether delegation as a language
construct has been underrated and whether Go now makes this
obvious.
-- Bienlein
Thanks for the example. To be honest the Go code looks like a
glorified version of JavaScript to me. I think it is way too
obfuscated, and Go syntax seems a bit like someone _always_
wanted to do it differently, just a personal preference, no
matter what people intuitively expect.[1]
x, y int
I prefer left-to-right:
type integer named x (or whatever), i.e. int x;
But why on earth (a []byte)? The type is important, not the name.
I can give it any name. a, inComing, inBytes, response,
draculaBytes ...
[1] Raises the question whether we've been conditioned by C or
whether C was intuitive.
Re: D vs Go in real life
Chris: But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ... I read that type array of byte(s), I find it a bit better than D syntax, especially when types become a little more complex. Bye, bearophile
Re: D vs Go in real life
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: [1] Raises the question whether we've been conditioned by C or whether C was intuitive. My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon. But what suprises me is that with a language feature as simple as delegates you can solve so many design problems that well. I wonder whether this is a result of a lot of thought or only a result of adding some language feature that frees you from having to write myStruct1-field1-myStruct2-field2- ...
Re: GUI libraries
On Friday, 29 November 2013 at 02:00:50 UTC, Chris Cain wrote: On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote: Still lacking proper beard ;) A programmer without a beard! Blasphemy! Witch! But anyway, going along with what you guys are saying, if you've ever seen reviews on Android apps, a lot of apps get lots of bad reviews for not adhering to the Android design standards. Using cross-platform toolkits are usually a death sentence for your rating. So, there's a lot to be said about making sure your app looks consistent in the OS it's running in. Some apps do get away with something that is somewhat custom. Take, for instance, Steam on Windows. It doesn't look like a proper Windows application, but it works very well for it regardless. That said, Steam on Mac is terrible because it feels too much like a windows app there (mainly in regards to scrolling behavior). That all said, if I were writing a GUI app in D right now, I would probably write my own toolkit and make something super simple (but good looking) to test out some new ideas. I think we really need an easy, straight-forward, and powerful UI toolkit that takes advantage of D's unique features (such as compile-time specialization, maybe using DSLs that compiled used at compile-time instead of runtime) while reflecting well in comparison to the newest paradigms of application design (think how Android iOS apps are made and maybe even a bit of web design). I can't quite precisely quantify what we need, but I think a fresh approach to the UI programming interface could set D apart in this area. Simply using a translation of an old UI toolkit is easy but will not make UI applications pleasing to develop. You actually put into words what I've been thinking. I know that people want native behavior, and maybe one day it will just be intuitive behavior instead of corporate OS behavior.[1] But with D we have a chance to do what you say in the last paragraph. [1] What we expect of a UI is what we've been made to believe to expect. It all boils down to Architect or Bee?
Re: D vs Go in real life
bearophile I wonder, if it's just the way I've learned how to program that I prefer byte[] buf; to buf []byte; // Which seems a bit awkward to me. it's called 'buf' and it is an array of ... of what Drum roll r-r-r-r-r ... Of bytes! Yeah!!! Maybe it's because in my culture we read (and think?) from left to right. Mind you, the apple symbol on the Mac is in the upper left corner. The Launcher in Ubuntu is on the left hand side by default. The folders and contacts in Gmail are on the left hand side. Your mouse cursor is in the left half of the screen most of the time. On Friday, 29 November 2013 at 12:16:07 UTC, Bienlein wrote: On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: [1] Raises the question whether we've been conditioned by C or whether C was intuitive. My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon. Very good point. But do we need to modernize C? C is only one step away form assembly. So if you modernize this, your still on the same level. But what suprises me is that with a language feature as simple as delegates you can solve so many design problems that well. I wonder whether this is a result of a lot of thought or only a result of adding some language feature that frees you from having to write myStruct1-field1-myStruct2-field2- ... I like structs and classes for the fact that they can handle stuff on their own. But we do have delegation in D and it is a useful feature in Objective-C too. structs/classes and delegation are not mutually exclusive. And your question is very good. Is delegation in Go a work around within a limited language or is it a design feature? If Go is modernized C, will it end up like C++?
Re: If you had money to place for a bounty, what would you choose?
On 2013-11-28 22:01, Fra wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be? Binary compatibility with Objective-C: http://michelf.ca/projects/d-objc/ Or dynamic libraries for Mac OS X. -- /Jacob Carlborg
Re: GUI libraries
On 2013-11-28 21:54, Xavier Bigand wrote: Yep, that the goal, having applications with a real personality. I don't think it's an issue especially when application is full screen and respect pictographs (icons and texts) standards,... real personality, it's more of trying to emulate the native toolkit to fails. Having custom UI can help applications to improve ergonomic with dedicated behaviors when it's needed. D itself isn't limited to one policy, you can do objects or not,... the only things that is important is to let a strong default couple of style and ergonomic without adding complexity for users want do some custom stuff. What is native on windows ? - Win32 - Winforms - Qt Widgets (that is near Win32)? And on linux ? - GTK (with gnome and KDE) - Qt QML (KDE future) A native UI isn't necessary considered as the standard one, maybe Qt have a chance to be a real standard (on many platforms). There's one thing in creating a completely new GUI, like games do, and a completely different thing in trying to emulate a native toolkit and fail. The above video is an example of the latter. -- /Jacob Carlborg
Re: D vs Go in real life
On Friday, 29 November 2013 at 12:53:02 UTC, Chris wrote: Very good point. But do we need to modernize C? C is only one step away form assembly. So if you modernize this, your still on the same level. Agree. If I accept a language that simple then it needs to deliver execution speed. And Go fails in that domain. delegation are not mutually exclusive. And your question is very good. Is delegation in Go a work around within a limited language or is it a design feature? The question I ask myself whether delegation is a nglected gross concept. I don't mean 1:1 associations as such, of course, but I mean that you can simply say myStruct1-fieldN instead of myStruct1-field1- ... myStructN-fieldN. But we do have delegation in D and it is a useful feature in Objective-C too. Concerning D you mean mixins? Yeah, I wonder why no JVM language has them. On the JVM all languages on a higher level than Java have chosen to go with traits only (Scala, Kotlin). Groovy has the @Delegate annotation, but the Groovy compiler doesn't complain in case some diamond problem pops up in your code. So it's not truly for real. With regard to Objective-C you mean the instancesRespondToSelector: thing? But this is some kind of hack. In Go the compiler checks for correctness. If Go is modernized C, will it end up like C++? Well, at least Go is very consistent. No tons of complicated special cases you need to know about. Rust did things very well here. It is made for speed and low memory consumption. The way it adds OO elements to the language is not that minimalistic. I don't see how Go can compete with Java when a company is already using Java as Go runs at about the same speed. They have done concurrency very well with goroutines and channels. Some of the excitement about Go clearly comes from concurrency being well done. They have a tool that can analyse the channels in some Go code and tell you whether a deadlock is inevitably bound to happen. That's not bad. I think Go is more for C or Python people and for Java/.NET people that want to do a little bit of system programming in their spare time. -- Bienlein
Re: If you had money to place for a bounty, what would you choose?
* ARC * rvalue - ref * virtual-by-default * GC improvements * AA fixes On 29 November 2013 07:01, Fra f...@b.it wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be?
Re: Should std.net.curl be moved from Phobos to Deimos?
On 2013-11-29 03:39, Andrei Alexandrescu wrote: We'll probably keep it but not advertise it. But you're making a terrible argument - you want us to keep a bankrupt artifact just because you don't want to update your code. That's the standard argument, can't remove/change this, will break backwards compatibility. -- /Jacob Carlborg
[Sharing] D's scope statement in C++ (Reddit)
Hi, I would like to share this article D's scope statement in C++ that I just found: http://cppsecrets.blogspot.ca/2013/11/ds-scope-statement-in-c.html Original source: http://www.reddit.com/r/programming/comments/1rp8es/c_secrets_ds_scope_statement_in_c/ Matheus.
Re: GUI libraries
On Friday, 29 November 2013 at 13:31:34 UTC, Jacob Carlborg wrote: On 2013-11-28 21:54, Xavier Bigand wrote: Yep, that the goal, having applications with a real personality. I don't think it's an issue especially when application is full screen and respect pictographs (icons and texts) standards,... real personality, it's more of trying to emulate the native toolkit to fails. Having custom UI can help applications to improve ergonomic with dedicated behaviors when it's needed. D itself isn't limited to one policy, you can do objects or not,... the only things that is important is to let a strong default couple of style and ergonomic without adding complexity for users want do some custom stuff. What is native on windows ? - Win32 - Winforms - Qt Widgets (that is near Win32)? And on linux ? - GTK (with gnome and KDE) - Qt QML (KDE future) A native UI isn't necessary considered as the standard one, maybe Qt have a chance to be a real standard (on many platforms). There's one thing in creating a completely new GUI, like games do, and a completely different thing in trying to emulate a native toolkit and fail. The above video is an example of the latter. It's not about emulating. It's about innovating. And as for the features of OSes, say the Preferences dialog on OS X, you could always interface to that, and only that. As platforms are becoming more diverse (Android, Ubuntu, OS X, Windows, Blackberry and whatnot) companies and programmers want a write-once-run-everywhere toolkit more than ever. Look at Gtk, Textadept even delivers the libraries on OS X. Self-catering is becoming more and more important as different OSes are being used.
Re: D vs Go in real life
On 2013-11-29 09:29, Bienlein wrote:
On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei Alexandrescu wrote:
Interesting. Could you please create a paste with the two code samples?
Thanks,
Andrei
Hello,
here is the Go code:
package main
import (
fmt
)
type Point struct {
x, y int
}
type Rectangular struct {
topLeft, bottomRight Point
}
func (self Rectangular) Left() int {
return self.topLeft.x
}
func (self Rectangular) Right() int {
return self.bottomRight.x
}
func (self Rectangular) Width() int {
return self.Right() - self.Left()
}
type Rectangle struct {
Rectangular
}
func NewRectangle(topLeft, bottomRight Point) *Rectangle {
rectangle := new(Rectangle)
rectangle.Rectangular.topLeft = topLeft
rectangle.Rectangular.bottomRight = bottomRight
return rectangle
}
func main() {
rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
fmt.Println(rectangle.Width())
}
And this is the Scala code:
import java.awt.Point
trait Rectangular {
protected val topLeft: Point
protected val bottomRight: Point
def width : Int = bottomRight.x - topLeft.x
}
class Rectangle(val topLeft: Point, val bottomRight: Point) extends
Rectangular
object RunIt extends Application {
val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
println(rectangle.width)
}
I guess in D you would do something like this:
mixin template Rectangular() {
Point x, y;
}
mixin Rectangular;
struct Rectangle {
mixin Rectangular;
}
Note that in the Scala code Rectangular.topLeft and
Rectangular.bottomRight are protected. Since the solution in Go makes
use of delegation this can only be accomplished in Go through making
getters public or defining Rectangle in the same package as Rectangular.
Since Go does not have constructors the way to initialize a Rectangle in
Go looks more clumsy.
An interesting point to me is that Rectangular in Go is just an ordinary
struct whereas Rectangular is a special construct in Scala (being a
trait) and in D (being a mixin). So Scala and D force you to design
ahead, e.g. you have to decide in advance whether to make Rectangular a
trait or mixin. Thereafter, Rectangular is not of use on its own, only
when used as a trait or mixin.
What makes me think is whether delegation as a language construct has
been underrated and whether Go now makes this obvious.
You can do the exact thing in D with the help of UFCS. BTW, you need to
decide in advance if you should use a class or a struct in D. That's
basically the same thing as choosing if you need a template.
--
/Jacob Carlborg
Re: D vs Go in real life
On 2013-11-29 06:14, brad clawsie wrote: this has been a great thread and I've found a lot of the replies very insightful. I've been programming in Go at work for about a year or so now, so I have some opinions on Go that I believe are reasonably informed, while I am still a D novice but hope to continue learning. First, let me say that it is obvious that, by design, D is a more powerful language than Go. Go's simplicity will either be an advantage or a deal-breaker based on who you ask. On my vps instance last night I tried to create an initial D programming environment, with the following tools: - dmd - dub - vibe.d - ldc (not strictly necessary but I've heard so many good things about it) First I tried installing dmd from source, which was fine but then I would get strange errors about referring to a file object.d when trying to build dub. Some poking around on the web resulted in the advice of installing the pre-built dmd binary that is in the release distribution. Now I was able to build dub, although it was strange to see two completely different build mechanisms for dmd and dub - dmd using a makefile and dub using a sh script wrapper. vibe.d was easier to install once dub worked. Over an hour just to get basic tools installed, although I feel HTTP serving is so common that it should be one of the accepted batteries included by default. If this were Go, I would have installed the default build for my platform and had an http server in my standard sdk and everything else available by go get, which has never failed to work flawlessly for me in a year of dealing with code from the web. This is one reason why there are already so many libraries for Go - it is trivial to expose your code to other developers via the supported toolchain. Why did you install dmd from source and not the same way as Go? It's a bit unfair comparison. Dub is a package manager for D, with many libraries available. -- /Jacob Carlborg
Re: Should std.net.curl be moved from Phobos to Deimos?
On Tuesday, 26 November 2013 at 19:21:31 UTC, Andrei Alexandrescu wrote: On 11/26/13 11:13 AM, Iain Buclaw wrote: Remembering to include '-lcurl' when importing std.net.curl is perhaps one urk. But this will be a no longer a problem if libphobos is built shared. Interesting. Can we supply a pragma that automates the flag thingie? Andrei It doesn't work: http://forum.dlang.org/thread/yosxnqziavcnnxkfh...@forum.dlang.org
Re: If you had money to place for a bounty, what would you choose?
On 29 November 2013 23:27, Jacob Carlborg d...@me.com wrote: On 2013-11-28 22:01, Fra wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be? Binary compatibility with Objective-C: http://michelf.ca/projects/d-objc/ I've been very excited about this for a long time... why is it sitting in limbo? How is the implementation? Is there a reason nobody seems to be actually considering it for inclusion? OSX/iOS are 2 very important platforms, and I too would really love to see movement on this work.
Re: GUI libraries
On 2013-11-29 14:53, Chris wrote: It's not about emulating. It's about innovating. Qt tries to emulate the native toolkit, like it or not. -- /Jacob Carlborg
Re: [Sharing] D's scope statement in C++ (Reddit)
On 2013-11-29 14:45, MattCoder wrote: Hi, I would like to share this article D's scope statement in C++ that I just found: http://cppsecrets.blogspot.ca/2013/11/ds-scope-statement-in-c.html Original source: http://www.reddit.com/r/programming/comments/1rp8es/c_secrets_ds_scope_statement_in_c/ This is nothing new. The Loki library contains a scope guard implementation, if I recall correctly. -- /Jacob Carlborg
Re: D vs Go in real life
On Friday, 29 November 2013 at 12:11:26 UTC, bearophile wrote: Chris: But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ... I read that type array of byte(s), I find it a bit better than D syntax, especially when types become a little more complex. Bye, bearophile byte array named a vs a is an array of bytes. Either is fine. I agree that sometimes the latter is better for complex types.
Re: D vs Go in real life
On 11/28/13 9:49 PM, Craig Dillabaugh wrote: On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote: This might not be a fair assessment given my shallow experience with D, but it seems much less polished relative to Go for setting up a development environment and working with code from the web. Well D is a volunteer effort while Go is being backed by the worlds biggest web company! That sort of accounts for that I suppose. There has been recognition in the community that this needs to improve, but progress is only so fast with the limited resources. Thanks Brad for the compare contrast. Craig, I think funding is part of the story but not all - our community could get better at being perfectionist about the out-of-the box experience. Go is underpowered but its good execution is undeniably attractive: the first experience, the implementation works as advertised, and the networking libraries show their authors' expertise. We stand to learn from that. Andrei
Re: If you had money to place for a bounty, what would you choose?
On 2013-11-29 15:08, Manu wrote: I've been very excited about this for a long time... why is it sitting in limbo? I don't know. It seems Walter don't want us to be worse than Objective-C, meaning he want ARC. But as far as I understand it, we couldn't come to an agreement on how to implement ARC. But to be able to be compatible with ARC in Objective-C we would need to follow that very How is the implementation? Unfortunately only for 32bit and the legacy runtime. iOS uses the modern runtime. It's also missing some features like blocks and categories. Is there a reason nobody seems to be actually considering it for inclusion? OSX/iOS are 2 very important platforms, and I too would really love to see movement on this work. I could try and get it up to date again, just do a pull and see what happens. -- /Jacob Carlborg
Re: D vs Go in real life
On Fri, 2013-11-29 at 13:11 +0100, bearophile wrote: Chris: But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ... I read that type array of byte(s), I find it a bit better than D syntax, especially when types become a little more complex. I believe it should be read as slice of bytes not array of bytes. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: D vs Go in real life
On Friday, 29 November 2013 at 05:51:48 UTC, Chris Cain wrote: The whole build process is a lot more involved than it really should be. Ideally you should be able to clone dmd, phobos, and druntime and just have everything compile and be put into a relative path together and just work. Maybe alert you if you don't have phobos and druntime to build. Ultimately, you really have to download the binary version if you want it to work transparently, but it would be nice if it were easy enough to build from source that a printed 1 page guide would get you 100% running. Huh? git clone https://github.com/D-Programming-Language/dmd.git git clone https://github.com/D-Programming-Language/druntime.git git clone https://github.com/D-Programming-Language/phobos.git cd ./dmd/src make -f posix.mak MODEL=64 RELEASE=1 cd ../../druntime make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 cd ../phobos make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 After that just make symlink to dmd binary and add Phobos/druntime paths to dmd.conf and you are ready to go.
Re: D vs Go in real life
On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: [1] Raises the question whether we've been conditioned by C or whether C was intuitive. I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading. http://c-faq.com/decl/spiral.anderson.html D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with types on the left of the name. After using a language doing it the right way for awhile, you quickly adapt and realize it makes the most sense. At least, that's the way that I feel.
Re: If you had money to place for a bounty, what would you choose?
On 11/29/13 5:43 AM, Manu wrote: * ARC * rvalue - ref * virtual-by-default * GC improvements * AA fixes These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Andrei
Re: [Sharing] D's scope statement in C++ (Reddit)
On 11/29/13 5:45 AM, MattCoder wrote: Hi, I would like to share this article D's scope statement in C++ that I just found: http://cppsecrets.blogspot.ca/2013/11/ds-scope-statement-in-c.html Original source: http://www.reddit.com/r/programming/comments/1rp8es/c_secrets_ds_scope_statement_in_c/ uncaught_exception? No, he's way off. Andrei
Re: D vs Go in real life
On Friday, 29 November 2013 at 08:35:58 UTC, Bienlein wrote: Could you just quickly describe what you mean by being forced to move lot of things to run-time? I simply don't see what you are refering to. For example the dreaded generics issue. You can workaround it in many cases by using common polymorphic storage types but it costs. Or some applications of declarative programming in D - one can avoid using reflection and just move base data to runtime values but that requires to do processing during runtime. In your Rectangular example the difference will start to appear when one wants to express a function that accepts any Rectangular type. As far as I know, in Go only option uses fat pointer. In D you can also express it as template constrain and thus can make more finely tuned design decision.
Re: Should std.net.curl be moved from Phobos to Deimos?
On 11/29/13 5:47 AM, Jacob Carlborg wrote: On 2013-11-29 03:39, Andrei Alexandrescu wrote: We'll probably keep it but not advertise it. But you're making a terrible argument - you want us to keep a bankrupt artifact just because you don't want to update your code. That's the standard argument, can't remove/change this, will break backwards compatibility. I'd say alternative installers are in a different category than user code. Anyhow, you are making a good point that if your tool is out there, others may be too. Andrei
Re: D vs Go in real life
On 2013-11-29 16:15, Dicebot wrote: After that just make symlink to dmd binary and add Phobos/druntime paths to dmd.conf and you are ready to go. dmd.conf.default is only for Linux. There's also no sc.ini for Windows. -- /Jacob Carlborg
Re: D vs Go in real life
On Friday, 29 November 2013 at 15:34:21 UTC, Jacob Carlborg wrote: On 2013-11-29 16:15, Dicebot wrote: After that just make symlink to dmd binary and add Phobos/druntime paths to dmd.conf and you are ready to go. dmd.conf.default is only for Linux. There's also no sc.ini for Windows. Pardon my ignorance, I have never used D on Windows. Well, I guess at least building part should be pretty much the same (afair make binary for Windows is in distribution)
Re: GUI libraries
On Friday, 29 November 2013 at 14:14:08 UTC, Jacob Carlborg wrote:
On 2013-11-29 14:53, Chris wrote:
It's not about emulating. It's about innovating.
Qt tries to emulate the native toolkit, like it or not.
I don't think it's necessary to do that. You actually only need a
small set of widgets (text fields, buttons, menus, tabs etc.) The
rest is just for show (and to tie programmers to one particular
platform!). Swing is a good example. There are excellent UI apps
written in Swing that run everywhere. I use jEdit a lot (not
exclusively but again and again), and it has everything you need.
A big advantage is cross-platform consistency. I think this is an
issue that is under-estimated. This is why I like Textadept and
jEdit.
Native behavior can still be added as in
version (Windows) {
menuInWindow;
preferencesIn(Tools (or Edit?));
}
version (OSX) {
menuNotInWindow;
preferencesIn(Preferences ...);
}
A small set of native interfaces (but no dependence on them!).
Re: If you had money to place for a bounty, what would you choose?
On Fri, Nov 29, 2013 at 01:52:19PM +1100, Daniel Murphy wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.152.1385681675.3242.digitalmar...@puremagic.com... One of the most problematic things is that its implementation is sprinkled throughout DMD (each bit interacting in intricate ways with its surroundings), object_.d (a sort of hybrid half-user, half-built-in struct AssociativeArray), and aaA.d (the core runtime implementation). Each of these pieces interact in complex ways with each other, and don't always share the same information together. We can at least fix the hybrid situation: https://github.com/D-Programming-Language/dmd/pull/2856 [...] Excellent!! This will cut my budget in half! ;-) What about the AA value type issue? T -- Life is all a great joke, but only the brave ever get the point. -- Kenneth Rexroth
Re: What is the current point to empty/null associative arrays?
On Fri, 29 Nov 2013 09:51:05 -, Peter Alexander
peter.alexander...@gmail.com wrote:
On Friday, 29 November 2013 at 09:39:57 UTC, Cooler wrote:
On Friday, 29 November 2013 at 08:48:03 UTC, Chris Cain wrote:
On Friday, 29 November 2013 at 08:32:12 UTC, Cooler wrote:
...
Try making fill array look more like this:
void fillArray(ref string[int] a) { a[10] = A; }
The issue is that an array (and/or associative array) is a value type.
Basically, you can look at it as a struct with a pointer (and some
extra info). If you don't pass it as a ref then reallocations (such as
what happens when you add an item to an empty AA) will cause the two
to not point to the same information anymore.
Adding ref is not an exit. I show this example only for simplicity.
In my real example I have to fill different AA base on condition:
string[int] aa1, aa2;
...
auto aaToFill = someCheck ? aa1 : aa2;
// Then do something with aaToFill
If aa1 is empty it will never be filled.
string[int]* aaToFill = someCheck ? aa1 : aa2;
(*aaToFill)[A] = 1;
Resorting to pointers = fail (for the language) I'm afraid.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D vs Go in real life
On Friday, 29 November 2013 at 15:21:26 UTC, Chris Cain wrote: On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: [1] Raises the question whether we've been conditioned by C or whether C was intuitive. I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading. http://c-faq.com/decl/spiral.anderson.html D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with types on the left of the name. After using a language doing it the right way for awhile, you quickly adapt and realize it makes the most sense. At least, that's the way that I feel. I agree that D, too, can be a bit confusing. I sometimes have problems with AA declarations. Example: string[string][string] hm; // What am I? But I don't think it's the reading direction. I wonder why you would want the variable name first. var omitNewline bool or func (r RepeatByte) Read(p []byte) (n int, err error) or := or var. _Of course_ it's a variable: bool yes; string answer; For my liking Go code looks too cluttered (pointing out the obvious). But I guess it's just the way you're brought up with a language. Maybe I'm a dinosaur.
Re: GUI libraries
On Wednesday, 27 November 2013 at 17:07:07 UTC, DLang Beginner wrote: Hello. I want to make GUI applications with D, but I don't know which are updated and ready to use, which are good and etc. Can you help me with choosing the right one, guys? I don't know which OS you're interested in, but for Windows I enjoyed using DFL, it's pretty good, easy to use and still maintained: https://github.com/Rayerd/dfl
Re: If you had money to place for a bounty, what would you choose?
On 30 November 2013 01:23, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 11/29/13 5:43 AM, Manu wrote: * ARC * rvalue - ref * virtual-by-default * GC improvements * AA fixes These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Sure, any tasks that lead towards those goals are within my interest :)
Re: D for Speech and Signal Processing
On Thursday, 28 November 2013 at 10:30:36 UTC, Chris wrote: There are voice analysis and speech processing toolkits like Covarep and Voicebox (see links below) that were coded in Matlab, because they were originally only prototypes. There has been talk of porting them to C++. My first thought, as you might imagine, was why not use D? However, I don't know if there are any performance issues, especially for real time systems (in speech recognition), talking about GC, or in fact any other issues (number grinding etc.). A lot of the analysis tools are based on some sort of HMM (http://en.wikipedia.org/wiki/Hidden_Markov_model) and I think D could handle that elegantly. https://github.com/covarep/covarep http://www.ee.ic.ac.uk/hp/staff/dmb/voicebox/voicebox.html Hi, I have a little experience in dsp programming using oop languages, so I'll try to give you my mind, but my mind is more related to entertainment dsp softwares (asio, vst, etc...). talking about GC In pseudo real time (RT) audio (one or many buffer are overlapped) you are a in a loop (interesting example is bufferswitch in asio). It's time critical and performance critical, so you'll never create a class neither allocate a buffer here...The idea is: what does trigger the GC: memory allocation and dynamic class instance creation. It's like in GUI programming: you don't destroy and recreate many objects in the resize/realign message handler...So the GC problem is solved: there is no GC problem because in RT dsp you won't do something stupid that'll trig a GC pass. In speech recognition you'll mostly use some frequency-domain technics (not to name the fft), so basically if you don't want to trigger a GC pass, don't use build-in array and make your own array using alloc/malloc/free. For the classes it's the same, you can still make your own class allocator/deallocator, like specified in the manual (even if they say it's deprecated). With user managed classes and array you'll avoid most of the GC passes...But it doesn't mean that the most important stuff is: not to allocate in the audio buffer loop.
Re: GUI libraries
On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote: Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes. This is pure Mac talk. In Windows the native UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages. Relying purely on native controls leads nowhere. And Linux notion of native is already discussed and destroyed before me.
Re: GUI libraries
On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand wrote: What is native on windows ? - Win32 - Winforms - Qt Widgets (that is near Win32)? I would say Win32. Winforms is mostly a thin wrapper over Win32. However things get more complicated if you take into account WPF (completely new written from scratch UI library which makes your app look a bit different and start in just 25 seconds ;) ) and Win 8 Metro UI, again based on different mechanisms and having completely different look and feel.
Re: If you had money to place for a bounty, what would you choose?
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be? https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful.
Re: D for Speech and Signal Processing
On Friday, 29 November 2013 at 16:58:47 UTC, Baz wrote: In speech recognition you'll mostly use some frequency-domain technics (not to name the fft), so basically if you don't want to trigger a GC pass, don't use build-in array and make your own array using alloc/malloc/free. For the classes it's the same, you can still make your own class allocator/deallocator, like specified in the manual (even if they say it's deprecated). With user managed classes and array you'll avoid most of the GC passes...But it doesn't mean that the most important stuff is: not to allocate in the audio buffer loop. From what I hear, Protools for Mac is especially demanding and needs no allocation in the audio thread. Some people have problems merely by acquiring a lock.
Re: Optlink and Avast
On Friday, 29 November 2013 at 03:58:59 UTC, Rikki Cattermole wrote: Has anyone else hit with Avast recognising Optlink as a suspicious file since last update? Since this spring I had issues when after linking my dmd-compiled program with libjpeg the result was reported to have something like Gen:Trojan.Heur.GM.0444140020 by several different antiviruses, including BitDefender, Comodo and F-Secure but not including Avast. What's interesting, when scanning the app without libjpeg linked in, it shows clean. When scanning libjpeg object file (which gets linked) it is clean too. But when the two are linked together antiviruses go mad. Example of scan: https://www.virustotal.com/en/file/808b46ee5cf568190b6075e39194b4442c0c3c36525d145ea546c2a3199265d8/analysis/1385745220/ Original file: https://bitbucket.org/infognition/bsort/downloads/blogsort.exe
Re: If you had money to place for a bounty, what would you choose?
On Fri, Nov 29, 2013 at 06:13:58PM +0100, Gary Willoughby wrote: On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be? https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful. +1. I have to admit I rarely use a debugger, but just this week, I had to debug a few segfaults in my D code, and trying to use gdb with a dmd-compiled executable was very painful. The debugger seemed to just jump about with only an approximate idea of where the code was actually going, and half the symbols weren't recognized. I had to resort to writeln debugging to track down the problem. I can see how someone used to a debugger would throw up their hands at this situation. T -- Never trust an operating system you don't have source for! -- Martin Schulze
Re: D for Speech and Signal Processing
On Friday, 29 November 2013 at 16:58:47 UTC, Baz wrote: On Thursday, 28 November 2013 at 10:30:36 UTC, Chris wrote: There are voice analysis and speech processing toolkits like Covarep and Voicebox (see links below) that were coded in Matlab, because they were originally only prototypes. There has been talk of porting them to C++. My first thought, as you might imagine, was why not use D? However, I don't know if there are any performance issues, especially for real time systems (in speech recognition), talking about GC, or in fact any other issues (number grinding etc.). A lot of the analysis tools are based on some sort of HMM (http://en.wikipedia.org/wiki/Hidden_Markov_model) and I think D could handle that elegantly. https://github.com/covarep/covarep http://www.ee.ic.ac.uk/hp/staff/dmb/voicebox/voicebox.html Hi, I have a little experience in dsp programming using oop languages, so I'll try to give you my mind, but my mind is more related to entertainment dsp softwares (asio, vst, etc...). talking about GC In pseudo real time (RT) audio (one or many buffer are overlapped) you are a in a loop (interesting example is bufferswitch in asio). It's time critical and performance critical, so you'll never create a class neither allocate a buffer here...The idea is: what does trigger the GC: memory allocation and dynamic class instance creation. It's like in GUI programming: you don't destroy and recreate many objects in the resize/realign message handler...So the GC problem is solved: there is no GC problem because in RT dsp you won't do something stupid that'll trig a GC pass. In speech recognition you'll mostly use some frequency-domain technics (not to name the fft), so basically if you don't want to trigger a GC pass, don't use build-in array and make your own array using alloc/malloc/free. For the classes it's the same, you can still make your own class allocator/deallocator, like specified in the manual (even if they say it's deprecated). With user managed classes and array you'll avoid most of the GC passes...But it doesn't mean that the most important stuff is: not to allocate in the audio buffer loop. Thanks. That's very interesting, I'll look into it.
Re: GUI libraries
On Friday, 29 November 2013 at 17:03:02 UTC, thedeemon wrote: On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote: Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes. This is pure Mac talk. +1 In Windows the native UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages. Relying purely on native controls leads nowhere. Yes. And Linux notion of native is already discussed and destroyed before me.
Re: If you had money to place for a bounty, what would you choose?
On 2013-11-29 14:08:25 +, Manu turkey...@gmail.com said: On 29 November 2013 23:27, Jacob Carlborg d...@me.com wrote: Binary compatibility with Objective-C: http://michelf.ca/projects/d-objc/ I've been very excited about this for a long time... why is it sitting in limbo? How is the implementation? Is there a reason nobody seems to be actually considering it for inclusion? OSX/iOS are 2 very important platforms, and I too would really love to see movement on this work. If I were Walter, I wouldn't accept it in the state it is currently in. The missing support for the modern runtime makes it look like a gimmick, as the legacy runtime is dead end (Apple is already dropping 32-bit support with new OS X frameworks). And no ARC makes it look bad compared to regular Objective-C. Lacking support for Objective-C categories and for blocks is also problematic. I'm no longer working on D/Objective-C. And while Jacob has updated it to a more modern incarnation of DMD, it's just the minimum to keep it afloat. What this project need is sustained development for I don't know how many months. The implementation is quite good, in my opinion. But then I'm the one who wrote it. ;-) The important thing to keep in mind is that this is a huge and far reaching changeset. It adds things in the parser, in the semantic phase, in code generation, in the back end, and in the runtime. It's full of internal design decisions which I didn't really discuss much with anyone, in most part because most people here are not familiar enough with Objective-C (be it the language, its runtime or its compiled representation) to know what to do. There's also some reverse engineering work to figure out the correct output for compiled code, as this is not much documented. Honestly, this thing is not mere bounty material, it'd be worthy to be a Kickstarter project for about a full year of development time. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: If you had money to place for a bounty, what would you choose?
On 2013-11-29 15:10:27 +, Jacob Carlborg d...@me.com said: On 2013-11-29 15:08, Manu wrote: I've been very excited about this for a long time... why is it sitting in limbo? I don't know. It seems Walter don't want us to be worse than Objective-C, meaning he want ARC. But as far as I understand it, we couldn't come to an agreement on how to implement ARC. But to be able to be compatible with ARC in Objective-C we would need to follow that very Actually, if you want ARC to be compatible with Objective-C, someone familiar with Objective-C memory management has to design and implement the thing. Anything designed to work for Objective-C can easily be retrofitted to work with other D types, but the reverse is not true. So I'd tend to say it'd be better to implement ARC as part of the D/Objective-C project first, otherwise you're trying to solve too many problems at the same time and it becomes a mess. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: If you had money to place for a bounty, what would you choose?
On Friday, 29 November 2013 at 00:52:27 UTC, Dicebot wrote: Nice game guess linked bug by poster nickname :) mine quite works
Re: If you had money to place for a bounty, what would you choose?
On Friday, 29 November 2013 at 17:14:00 UTC, Gary Willoughby wrote: On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote: Personally I would love to see this old issue finally implemented/fixed: There can be only one alias this. https://d.puremagic.com/issues/show_bug.cgi?id=6083 What would your choice be? https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful. ++1++
std.allocator suggestions
1. Allocator which preallocates a fixed amount of extra bytes for each chunk, so that reallocations within that limit are guaranteed to be in-place. Multiple reallocations should be supported, too, e.g. if the limit is 10 it allocates 210 bytes when 200 are requested and then reallocs 200 - 205 - 203 - 210 are all in-place. 2. Allocator similar to Region that counts numbers of allocations/deallocations, and once the difference reaches zero, reuses the buffer instead of returning null. 3. Same as above but instead calls deallocate when difference reaches zero. This would allow to use regions allocated by malloc with cascading allocator.
Re: Should std.net.curl be moved from Phobos to Deimos?
On 11/27/2013 12:07 AM, Andrei Alexandrescu wrote: My conclusion after this whole discussion: in the short term we need to have both Fedora and Debian builds. Then we'll move from there. Right, different distributions = different shared libraries.
Re: GUI libraries
On 2013-11-29 18:03, thedeemon wrote: This is pure Mac talk. In Windows the native UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages. Relying purely on native controls leads nowhere. And Linux notion of native is already discussed and destroyed before me. That's why Mac OS X is so great, it's consistent :). But Apple creates custom controls as well. An example is the tabs available in Safari and Xcode. Other applications are trying to emulate them with various degrees of success. Path Finder does a very good emulation of Safari tabs. -- /Jacob Carlborg
Re: GUI libraries
On Thursday, 28 November 2013 at 14:49:33 UTC, Chris wrote: On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote: On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote: What I meant was no bindings to native widgets or other toolkits. DWT (like SWT) uses the native widgets and needs an interface. I was thinking of a toolkit where everything is provided by D and done in D without any reference to native frameworks (Cocoa etc.). Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes. For instance, take Viber for the Mac: what could be a great application (most of the complexity of a VoIP app isn't even in the UI), has awkward behaviors (e.g., the scrolling panes don't implement rubber banding, which makes them feel extremely unresponsive in OS X), badly imitated controls (e.g., the chat text box context menu, in OS X at least), etc. Features which are both complex and subtle like internationalisation also tend to break. The situation was already bad when the Windows, Mac and Linux interfaces were, overall, pretty similar (many of the non-optimal design decisions in apps with non-native UIs tended to appear where there were differences, such as in OS X global menus vs Windows' per window menus). With the trend toward newer and more diverse interface approaches, such as attempts to try to bring traditional computers to touch screen hardware, non-native UIs will tend to perform even worse, feeling even more alien to the end users. I don't know, but there are apps out there that do their own thing rather than relying on the system. I think Chrome and Opera are implemented like that. The thing is that people are getting used to different UIs now, because they use e.g. an iPad, an Android phone and a Windows PC (both privately and at work). So maybe everything is going in the direction of common UI features. Take for example multi-touch. Years ago Apple was way ahead (zooming in and out, rotating pictures etc.). Now most touch screen devices feature the same set of movements (e.g. scroll with middle and ring finger on track pad). Also, when writing bindings to native widgets, you're always playing catch-up too. Once you've got your bindings, the native toolkit has new methods, features and classes. I still think it would be good to have an independent GUI toolkit, like Java Swing / FX as opposed to SWT. Current Opera stuff is everything javascript.The setting page is a js stuff the download page is a js stuff...And everybody complain about this: js ans css. Seriously, opera is not anymore a good example.
Re: GUI libraries
Le 29/11/2013 03:00, Chris Cain a écrit : On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote: Still lacking proper beard ;) A programmer without a beard! Blasphemy! Witch! But anyway, going along with what you guys are saying, if you've ever seen reviews on Android apps, a lot of apps get lots of bad reviews for not adhering to the Android design standards. Using cross-platform toolkits are usually a death sentence for your rating. So, there's a lot to be said about making sure your app looks consistent in the OS it's running in. Some apps do get away with something that is somewhat custom. Take, for instance, Steam on Windows. It doesn't look like a proper Windows application, but it works very well for it regardless. That said, Steam on Mac is terrible because it feels too much like a windows app there (mainly in regards to scrolling behavior). That all said, if I were writing a GUI app in D right now, I would probably write my own toolkit and make something super simple (but good looking) to test out some new ideas. I think we really need an easy, straight-forward, and powerful UI toolkit that takes advantage of D's unique features (such as compile-time specialization, maybe using DSLs that compiled used at compile-time instead of runtime) while reflecting well in comparison to the newest paradigms of application design (think how Android iOS apps are made and maybe even a bit of web design). I can't quite precisely quantify what we need, but I think a fresh approach to the UI programming interface could set D apart in this area. Simply using a translation of an old UI toolkit is easy but will not make UI applications pleasing to develop. +1 For my work I work on a huge application that was actually only available on iOS, with his interface wrote in cocoa. The next version will be ported to iOS, Android, Windows and Mac OS X (maybe linux), so we completely rewrite the interface with QML, because to increase the application identity over multiple platforms and provide something really easy to use for customers. Providing an UI that match to mobile ones will remove the apprehension of users instead of Widgets making the application looks like a professional tool. I also think that professionals want beautiful apps too, just take a look to Visual, less and less developers want use vim or emacs. A lot of progress have to be done on UI and I don't think that it will necessary impulse by OS developers.
Re: GUI libraries
Le 29/11/2013 14:31, Jacob Carlborg a écrit : On 2013-11-28 21:54, Xavier Bigand wrote: Yep, that the goal, having applications with a real personality. I don't think it's an issue especially when application is full screen and respect pictographs (icons and texts) standards,... real personality, it's more of trying to emulate the native toolkit to fails. Having custom UI can help applications to improve ergonomic with dedicated behaviors when it's needed. D itself isn't limited to one policy, you can do objects or not,... the only things that is important is to let a strong default couple of style and ergonomic without adding complexity for users want do some custom stuff. What is native on windows ? - Win32 - Winforms - Qt Widgets (that is near Win32)? And on linux ? - GTK (with gnome and KDE) - Qt QML (KDE future) A native UI isn't necessary considered as the standard one, maybe Qt have a chance to be a real standard (on many platforms). There's one thing in creating a completely new GUI, like games do, and a completely different thing in trying to emulate a native toolkit and fail. The above video is an example of the latter. QML and mostly Qt Quick Controls are really young technologies and certainly not finished. The important things of Quick Controls is that it provides the default skin of the OS and the correct behaviors, but It's preferable to adapt it to import a custom Skin. Digia certainly think that it's important to simplify the transition between old (OS natvie UI) and new (fully custom UI) usages.
Re: GUI libraries
Le 29/11/2013 18:08, thedeemon a écrit : On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand wrote: What is native on windows ? - Win32 - Winforms - Qt Widgets (that is near Win32)? I would say Win32. Winforms is mostly a thin wrapper over Win32. However things get more complicated if you take into account WPF (completely new written from scratch UI library which makes your app look a bit different and start in just 25 seconds ;) ) and Win 8 Metro UI, again based on different mechanisms and having completely different look and feel. So you just tell that on Windows itself there is no real native UI, it changes. And now when you use Windows 8 you have some old applications based on Win32 UI that looks horrible and not well integrated. In this case natives aren't better.
Re: GUI libraries
Le 29/11/2013 04:48, Rikki Cattermole a écrit :
On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
On Thursday, 28 November 2013 at 12:05:09 UTC, Jacob Carlborg wrote:
On 2013-11-28 11:12, Chris wrote:
+1 GtkD Glade (UI builder) are very good (http://gtkd.org/).
Hopefully
one day we will have our own pure D GUI toolkit.
DWT is a pure D GUI toolkit.
What I meant was no bindings to native widgets or other toolkits. DWT
(like SWT) uses the native widgets and needs an interface. I was
thinking of a toolkit where everything is provided by D and done in D
without any reference to native frameworks (Cocoa etc.).
DOOGLE[1] currently only depends on libfreetype2, (with Windows as only
target) Windows API and OpenGL. I would remove libfreetype2 but.. its
basically standard for font rasterization cross platform wise.
I have designed it to have its interface abstracted away from the
implementation fully.
Its current state is well listed on my blog[2] it may not look much now
and not ready for production use, but definitely should be said.
[1] https://github.com/rikkimax/doogle
[2]
http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html
You may want take a look to DQuick :
https://github.com/D-Quick/DQuick
It's run on top of openGL too, the main difference is that you describe
the UI in dedicated script files. Scripts provide allow to provide fully
dynamical UIs.
An UI file (original lua script format for the moment) :
GraphicItem
{
id = main,
Image {
id = kerningImageButton,
source = images/border-image.png,
width = 300,
height = 50,
MouseArea {
id = kerningButton,
width = function()
return kerningImageButton.width
end,
height = function()
return kerningImageButton.height
end,
},
},
ScrollView {
id = scrollView,
y = function()
return kerningImageButton.height
end,
width = function()
return main.width
end,
height = function()
return main.height - scrollView.y
end,
clip = true,
Text {
id = text,
wrapMode = Text.WrapMode.WordWrap,
width = function()
return scrollView.width
end,
height = function()
return scrollView.height
end,
text = textFr,
family = function()
if (kerningButton.pressed) then
return AngsanaUPC
end
return Arial
end,
fontSize = 24,
fontStyle = function()
if (kerningButton.pressed) then
return Text.FontStyle.Italic
end
return Text.FontStyle.Regular
end,
},
},
}
Re: GUI libraries
On Friday, 29 November 2013 at 17:03:02 UTC, thedeemon wrote: On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote: Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes. This is pure Mac talk. In Windows the native UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages. Relying purely on native controls leads nowhere. You are discussing the creation of custom controls, while I was discussing the use of GUI libraries that recreate from scratch things like: - all controls, even the basic ones - UI behaviours (e.g., scrolling, double click times, etc.), badly mimicking the native system - text rendering, unicode/localization processing, etc. - integration with the native accessibility features - event processing Is possible to create custom controls while still playing relatively nice with the native UI platform, and thus avoid *some* of the problems mentioned, by inhering as much from the platform as possible (text rendering, scrolling, accessibility, etc.). For Apple platforms the advice is to avoid custom controls when possible, which became easier in iOS when the native controls became more skinnable. When custom controls are needed they still integrate with the platform to a reasonable extent, and thus while the *look* may be foreign, the *behaviours* tend to feel native.
Re: D for Speech and Signal Processing
I'm also waiting on D to address garbage collection better. As has been brought up multiple times before (then quickly forgotten), a @nogc attribute would do wonders for those D programmers looking to avoid sneaky GC allocations. That's a great start, and then we can work out how best to handle the parts of Phobos that currently allocate. I would tackling this myself if I had the skill.
Re: GUI libraries
On 11/29/13 9:03 AM, thedeemon wrote: On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote: Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes. This is pure Mac talk. In Windows the native UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages. Relying purely on native controls leads nowhere. I haven't used Windows in a while, but even years ago Office and MSVC were heavy-hitters that notably diverged from Windows' own widgets (and even interface design guidelines). These were (and are) immense and immensely successful applications that for which designing specific widgets was a small incremental cost (and I speculate a way to say we own the OS so we may as well design widgets that nobody else got). Most other Windows program were (and may as well still be, I haven't followed) totally fine with the stock widgets. Andrei
Re: If you had money to place for a bounty, what would you choose?
On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote: On 11/29/13 5:43 AM, Manu wrote: * ARC * rvalue - ref * virtual-by-default * GC improvements * AA fixes These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Andrei A bite-sized GC-related improvement is the @nogc attribute I've been craving for for quite some time. See: https://d.puremagic.com/issues/show_bug.cgi?id=5219 If I had money, I'd be putting it on this for sure. For system and game programmers it's a godsend, and it will put some C++ fanatics at ease with D's GC. With this feature I can protect the critical sections of my code with a firm guarantee that I won't see any unexpected activity from the GC.
Re: Optlink and Avast
On Friday, 29 November 2013 at 17:20:17 UTC, thedeemon wrote: On Friday, 29 November 2013 at 03:58:59 UTC, Rikki Cattermole wrote: Has anyone else hit with Avast recognising Optlink as a suspicious file since last update? Since this spring I had issues when after linking my dmd-compiled program with libjpeg the result was reported to have something like Gen:Trojan.Heur.GM.0444140020 by several different antiviruses, including BitDefender, Comodo and F-Secure but not including Avast. What's interesting, when scanning the app without libjpeg linked in, it shows clean. When scanning libjpeg object file (which gets linked) it is clean too. But when the two are linked together antiviruses go mad. Example of scan: https://www.virustotal.com/en/file/808b46ee5cf568190b6075e39194b4442c0c3c36525d145ea546c2a3199265d8/analysis/1385745220/ Original file: https://bitbucket.org/infognition/bsort/downloads/blogsort.exe Avast reports no threat on that file you provided.
Re: GUI libraries
On Friday, 29 November 2013 at 23:46:02 UTC, Xavier Bigand wrote:
Le 29/11/2013 04:48, Rikki Cattermole a écrit :
On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
On Thursday, 28 November 2013 at 12:05:09 UTC, Jacob Carlborg
wrote:
On 2013-11-28 11:12, Chris wrote:
+1 GtkD Glade (UI builder) are very good
(http://gtkd.org/).
Hopefully
one day we will have our own pure D GUI toolkit.
DWT is a pure D GUI toolkit.
What I meant was no bindings to native widgets or other
toolkits. DWT
(like SWT) uses the native widgets and needs an interface. I
was
thinking of a toolkit where everything is provided by D and
done in D
without any reference to native frameworks (Cocoa etc.).
DOOGLE[1] currently only depends on libfreetype2, (with
Windows as only
target) Windows API and OpenGL. I would remove libfreetype2
but.. its
basically standard for font rasterization cross platform wise.
I have designed it to have its interface abstracted away from
the
implementation fully.
Its current state is well listed on my blog[2] it may not look
much now
and not ready for production use, but definitely should be
said.
[1] https://github.com/rikkimax/doogle
[2]
http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html
You may want take a look to DQuick :
https://github.com/D-Quick/DQuick
It's run on top of openGL too, the main difference is that you
describe the UI in dedicated script files. Scripts provide
allow to provide fully dynamical UIs.
An UI file (original lua script format for the moment) :
GraphicItem
{
id = main,
Image {
id = kerningImageButton,
source = images/border-image.png,
width = 300,
height = 50,
MouseArea {
id = kerningButton,
width = function()
return kerningImageButton.width
end,
height = function()
return kerningImageButton.height
end,
},
},
ScrollView {
id = scrollView,
y = function()
return kerningImageButton.height
end,
width = function()
return main.width
end,
height = function()
return main.height - scrollView.y
end,
clip = true,
Text {
id = text,
wrapMode = Text.WrapMode.WordWrap,
width = function()
return scrollView.width
end,
height = function()
return scrollView.height
end,
text = textFr,
family = function()
if (kerningButton.pressed) then
return AngsanaUPC
end
return Arial
end,
fontSize = 24,
fontStyle = function()
if (kerningButton.pressed) then
return Text.FontStyle.Italic
end
return Text.FontStyle.Regular
end,
},
},
}
I know, I've kept an eye on all other GUI toolkits since I
started work. I'm currently sticking to just plain old class
objects to build it primarily because of a) efficiency and b)
extra dependencies.
Eventually there will be a meta based system to configure it. But
that'll come when I'll start on an IDE.
Re: GUI libraries
On Friday, 29 November 2013 at 02:00:50 UTC, Chris Cain wrote: On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote: Still lacking proper beard ;) A programmer without a beard! Blasphemy! Witch! But anyway, going along with what you guys are saying, if you've ever seen reviews on Android apps, a lot of apps get lots of bad reviews for not adhering to the Android design standards. Using cross-platform toolkits are usually a death sentence for your rating. So, there's a lot to be said about making sure your app looks consistent in the OS it's running in. Some apps do get away with something that is somewhat custom. Take, for instance, Steam on Windows. It doesn't look like a proper Windows application, but it works very well for it regardless. That said, Steam on Mac is terrible because it feels too much like a windows app there (mainly in regards to scrolling behavior). That all said, if I were writing a GUI app in D right now, I would probably write my own toolkit and make something super simple (but good looking) to test out some new ideas. I think we really need an easy, straight-forward, and powerful UI toolkit that takes advantage of D's unique features (such as compile-time specialization, maybe using DSLs that compiled used at compile-time instead of runtime) while reflecting well in comparison to the newest paradigms of application design (think how Android iOS apps are made and maybe even a bit of web design). I can't quite precisely quantify what we need, but I think a fresh approach to the UI programming interface could set D apart in this area. Simply using a translation of an old UI toolkit is easy but will not make UI applications pleasing to develop. +1 This is why with DOOGLE I have made shaders for e.g. controls completely overridable at app, system and user levels. Shaders control all looks of the app. Although this does mean a bit of calculation and binding of information regarding screen and component size. What does this mean? Maintainers for a distro or OS can easily make it look like what is expected for that OS. With regards to feel that would have to be hard coded at this point. Is it just me or is a button a layout? As far as I'm aware most gui toolkits think of it as not. It gives much more control over it. Just my 2 cents over how I feel with them. Eventually I would like to have DOOGLE emit html/css/js and work like GWT (Google Web Toolkit [1]). This really would be hugely beneficial for making a desktop application into a web app. And set it apart. [1] http://www.gwtproject.org/
Re: What is the current point to empty/null associative arrays?
On Friday, 29 November 2013 at 15:55:57 UTC, Regan Heath wrote:
On Fri, 29 Nov 2013 09:51:05 -, Peter Alexander
peter.alexander...@gmail.com wrote:
On Friday, 29 November 2013 at 09:39:57 UTC, Cooler wrote:
On Friday, 29 November 2013 at 08:48:03 UTC, Chris Cain wrote:
On Friday, 29 November 2013 at 08:32:12 UTC, Cooler wrote:
...
Try making fill array look more like this:
void fillArray(ref string[int] a) { a[10] = A; }
The issue is that an array (and/or associative array) is a
value type. Basically, you can look at it as a struct with a
pointer (and some extra info). If you don't pass it as a ref
then reallocations (such as what happens when you add an
item to an empty AA) will cause the two to not point to the
same information anymore.
Adding ref is not an exit. I show this example only for
simplicity. In my real example I have to fill different AA
base on condition:
string[int] aa1, aa2;
...
auto aaToFill = someCheck ? aa1 : aa2;
// Then do something with aaToFill
If aa1 is empty it will never be filled.
string[int]* aaToFill = someCheck ? aa1 : aa2;
(*aaToFill)[A] = 1;
Resorting to pointers = fail (for the language) I'm afraid.
R
How so? Only pointer arithmetic is unsafe. Pointers themselves
are perfectly fine and safe.
