Re: New Initiative for Donations

[Nick Sabalausky via Digitalmars-d-announce]

On Friday, 26 October 2018 at 02:38:08 UTC, Joakim wrote:
On Thursday, 25 October 2018 at 22:35:40 UTC, Nick Sabalausky 
wrote:


And yet it's still by far the most common payment method. So 
what if it isn't trendy. Deal with it.


In the US maybe, not in most of the world, where they're still 
using cash. ;) I almost never use my cards, and like that 
crypto-currencies have more in similar to cash.


I was referring to internet payments, as that was the 
conversation's context.


And you're right that cash is extremely common outside the net. 
Note that cash is considerably older than even credit/debit cards.



On Thursday, 25 October 2018 at 23:10:50 UTC, H. S. Teoh wrote:


Common fallacy: new == better.


As with D, sometimes the new _is_ better, so perhaps you 
shouldn't assume old is better either.


Nobody claimed otherwise.

Re: New Initiative for Donations

[Nick Sabalausky via Digitalmars-d-announce]

On Wednesday, 24 October 2018 at 10:25:17 UTC, Joakim wrote:
On Wednesday, 24 October 2018 at 10:18:51 UTC, Mike Parker 
wrote:

On Wednesday, 24 October 2018 at 10:12:50 UTC, Joakim wrote:



Any effort underway to take Bitcoin Cash, Ether, or Ripple as 
donations? The current payment options seem fairly 
antiquated: credit cards, wire transfers, and the like.


Not that I'm aware of. I'd hardly call credit cards 
antiquated, though :-)


60-year old tech seems pretty old to me:

https://en.m.wikipedia.org/wiki/Credit_card#BankAmericard_and_Master_Charge



And yet it's still by far the most common payment method. So what 
if it isn't trendy. Deal with it.

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky via Digitalmars-d-announce]

On Saturday, 9 June 2018 at 00:54:08 UTC, Kapps wrote:


Personally I think the fear of Microsoft ruining GitHub is 
completely unfounded. Just look at what they did to Xamarin. 
They bought an interesting product and then made it free for 
individuals, open sourced it, and improved it drastically. And 
they sure do hate Linux nowadays with dotnet CORE being 
partially to improve Linux / cross-platform support.


These days, I don't think the "evil" of MS is the thing to be 
concerned about. I'm more concerned about unpredictably and 
unreliability. The potential for mess-ups or mind-changing or 
other surprises down the road. Not that it necessarily WILL 
happen, but I think being MS its worth being prepared, just in 
case.

Re: Documentation for any* dub package, any version

[Nick Sabalausky via Digitalmars-d-announce]

On Tuesday, 27 February 2018 at 15:49:37 UTC, Basile B. wrote:


At first glance i can say that this will work perfectly for DUB 
packages. Once DCD gives a file, the IDE just have to look the 
parent folders to get the SemVer tag.
If the file is in a git repository things might be more 
complicated.


In most cases its pretty easy from a git repo too, just run 'git 
describe'. That'll give you the latest (annotated) tag (which 
SHOULD be the semver number, and generally is for dub projects) 
and no other output. Nothing to parse or scrape.


If theres been extra commits since the last tag, then there's a 
little extra suffix appended to git describe's output, but its 
trivial enough to parse/remove if you need to.

Re: two points

[Nick Sabalausky via Digitalmars-d-announce]

On 02/09/2017 04:49 AM, Walter Bright wrote:

On 2/8/2017 11:09 PM, Nick Sabalausky wrote:

And any PRs I have managed to get through were all uphill battles the
whole way.


You have contributed 5 PRs to dmd:

   https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa

 1 is open (it's controversial)

 1 closed (today by me)


Well, I suppose I brought that one on myself by complaining about it 
being ignored :/




 3 merged
 1 in 6 days
 2 in 1 day

Overall, I think you've done well.


Note that those quickly merged ones were several years ago, back before 
the battles to get anything accepted reached ridiculous levels.




In any case, shouldn't it be an uphill battle to merge things?


No. There should be appropriate checks and reviews, yes. But, no, every 
little fix and improvement shouldn't feel like trying to get somewhere 
in a year-long tabs vs spaces debate or making a big-budget sales pitch 
to Indecisives Anonymous.

Re: two points

[Nick Sabalausky via Digitalmars-d-announce]

On 02/09/2017 01:08 AM, Joakim wrote:

I agree that "coercion," or more accurately the tyranny of the default,
is the dominant factor in language popularity even today, but you're
reaching when you apply that to web frameworks too.


Fair enough. It was just another example trying to make the point that 
"if you want to do X, then you have little choice but use Y" is, as you 
say, the dominant factor in language popularity. I can grant that the 
web framework examples are weaker examples.



D's problem on the client is that the popular platforms are still very
much tied to certain favored languages:

iOS - ObjC and Swift
Android non-game apps - Java
Android games - C/C++
Windows - C# or C++
Web - Javascript

Three of the four major client platforms all allow other languages (with
the fourth starting to with WebAssembly), but you're often fighting the
tide if you choose a non-default language so most don't bother.


That's a good way of explaining it, I like that.


We can make the dev experience more pleasant on those platforms, as I
believe has happened now that we support the MS toolchain on Windows,
but D is unlikely to become popular without a killer app that
demonstrates its suitability.  That's not coercion, but something we can
actually control.


I hope you're right, but I worry that even "killer app example" may not 
be enough, and that the lack of one may turn out to be just another red 
herring excuse for "why aren't using D". After all, I think vibe's 
approach to server development comes very close to "killer app" yet, far 
as I've seen, it doesn't appear to have proven a major win for D so far.


Then again, having D in the "my secret weapon" category has certain 
benefits, too, so I guess I can't be TOO sour ;)



On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:

I think the D leadership are too busy addressing broader issues with
the language at the moment, so this specific case is just not a high
priority.  Also, if it's not a priority to the them, then anyone that
does attempt to work on it will just suffer an eternity in pull
request purgatory.

So, I would not recommend it as a project for anyone until the D
leadership decides to get involved.


I think this misunderstands how open source works: the whole point is
that you don't need anybody's permission to go do this. Walter and
Andrei, or any other OSS core team, are much more likely to approve
something if you have an implementation that works well.  Look at Ilya
and what happened after he showed them Mir.



You're right, in theory. But Mike is unfortunately very right about the 
whole "suffer an eternity in pull request purgatory."


I fixed an issue where "///"-style doc comments resulted in excessive 
paragraph breaks...must've been over a year ago. Simple fix for a 
nagging bug. The fix worked. Caused no problems. No controversy. And to 
this day, just went completely ignored despite my periodic nagging about 
it. Eventually got tired wasting my time babysitting the constant need 
for rebasing and manual merge fixes just for something that proved 
guaranteed to be ignored. And any PRs I have managed to get through were 
all uphill battles the whole way.


We have far too high a threshold for letting things actually happen. It 
didn't used to be that way, and that was a key reason why D became as 
good as it's gotten in the first place.


So I'm not surprised people familiar with D go to lengths to avoid 
putting the effort into PRs that are much more major than my 
comparatively trivial PRs: It's proven to come with a depressingly high 
likelihood of turning out to be a complete waste of time.


At the risk of sounding hyperbolic, I think this is D's next biggest 
problem after the lack of any "If you want to do X, your only real 
choice is D". Though I admit I might be a little biased on this 
particular point though.

Re: Questionnaire

[Nick Sabalausky via Digitalmars-d-announce]

On 02/08/2017 01:27 PM, Ilya Yaroshenko wrote:

1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some tasks
then with any other system language


x. Because I'm self-employed so I get to choose the best tool for the 
job instead of whatever some know-nothing manager thinks "must be good 
because its popular". Also, all of the above.



2. Does your company uses C/C++, Java, Scala, Go, Rust?


Not when I can help it.


3. If yes, what the reasons to do not use D instead?


If, for whatever reason, my hands are tied and it's just not a 
possibility. Usually platform/framework compatibility. Or somebody above 
me deciding "You must use language X". (But, after having had more than 
enough PHP/VB/Java/C++/Python/etc in my life, I'm more inclined now to 
simply avoid situations that would involve such restraints. Life's too 
short to suffer bad tools for bad reasons.)



2. Have you use one of the following Mir projects in production:


No. I keep hearing about Mir, but still haven't quite wrapped my head 
around what it is, or how/where to use it. (and that bugs me)



3. If Yes, can Mir community use your company's logo in a section "Used
by" or similar.


N/A


4. Have you use one of the following Tamedia projects in your production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount


First I've heard of them. I'll take a look.


5. What D misses to be commercially successful languages?


A groupthink mentality and loads of bad ideas and broken reasoning. Ie, 
the basic requirements for anything to be popular in the computing arena.


Seriously. I'm not joking.

Well, that and, nobody's ever really been in a situation where they're 
more or less FORCED to use D. Many, heck probably most, big-name 
languages got big because there were enough people who didn't have much 
of a choice:


- Earlier days of Unix/Linux dev? Hard to avoid C/C++.
- Work for a company that's heavily invested in MS tools? Hard to avoid 
VB (90's) or C# (2000's).
- Work for a non-MS-based enterprise? Hard to avoid Java, because that's 
what the higher-ups had already been sold on.

- Need to use a relational DB? SQL, period.
- Need client-side scripting on a web page? JavaScript, period (until 
just recently).
- If you wanted an MVC web framework, for a short while Ruby was the 
only choice. I guarantee Ruby would be more popular today if that time 
period had been longer. It's undeniable nobody would've ever heard of 
Ruby were it not for Rails.
- Need to run something on an affordable commodity server in the late 
90's/2000's? PHP, period. Unless you paid an extra $5-$10/mo. and 
restricted your choice of providers - then you could use VBScript/ASP, 
which was basically the same exact thing as PHP, but just incompatible.
- Need low-level hardware access, memory management or other direct 
control over performance and resource usage? Until recently, had to be 
C/C++.


Then once onboard, stockholm syndrome sets in. Instant popularity.

Coercion (and perceived coercion[1] for that matter) makes technologies 
popular far more than any other factor. The computing sector is NOT a 
meritocracy, not by a longshot. That right there is D's #1 biggest 
marketing flaw, period. If you nail that coercion part, it doesn't 
matter HOW badly you do on any other technical or marketing aspect. Been 
proven time and time again. And if you DON'T have that coercion, you 
face an uphill battle no matter how good you do on technical and 
marketing fronts. Also been proven time and time again.


[1] The "I must keep up or get left behind" thought train. See also 
"Cover Fire" and the Fire and Motion stuff here: 
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/



6. Why many topnotch system projects use C programming language nowadays?


Partly inertia, but also because there was a decade or two (that only 
ended a few years ago) where nearly all language designers obsessed over 
VMs and eliminating low-level capabilities, and in general dumbing down 
their languages to the point of uselessness for anyone but novices, 
hobbyists, and those who could afford to throw money/hardware at any and 
all performance/resource/scalability issues[2]. Because of that, for 
many C/C++ users, there simply was no realistic alternative, period.


[2] I'm sure 90's Sun LOVED their JVM/Java - it virtually guaranteed 
"optimization" could only mean "rent/buy more hardware" - Everything 
else besides reducing algorithmic complexity was deliberately banned by 
both the language and the VM...as a self-proclaimed "feature" no less. 
That "feature" allegedly being for safety, but decades of security 
patches and exploits for every VM on the planet proved that to be a load 
of...male cow.

Re: mysql-native: preview3 (docs)

[Nick Sabalausky via Digitalmars-d-announce]

https://github.com/Abscissa/mysql-native-experimental
Tag: v0.2.0-preview3

Just a few doc updates this time:

- Docs now include the `mysql.db.MysqlDB` to `mysql.pool.MySqlPool` 
change from preview2

- Clarified "Prepared" vs "PreparedImpl"
- Clarified "exec" vs "query"
- Rewrite the docs for ResultSet and ResultRange.

New docs:
http://semitwist.com/mysql-native-docs/v0.2.0-preview3

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 09:46 AM, Suliman wrote:

Could you explain real case if rangification of ResultSet

http://semitwist.com/mysql-native-docs/v0.2.0-preview1/mysql/result/ResultSet.html


Does it's mean that I can write
foreach(x;result.empty) ? Or how to use it?


.empty just checks whether the range is empty, it returns true/false. 
You can't iterate over that. But yes, you can iterate over the ResultSet 
itself. Of course, ResultSet is random-access, so you can also index it 
like an array: "resultset[0]" returns the first row.

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 02:22 AM, Suliman wrote:
> Am I right understand that if I use pool I can create connection
> instance one time in DB class constructor end every new connection
> will be created on demand?

No. You create the pool once (wherever/whenever you want to). Then, 
every time you want to use the database you obtain a connection by 
calling MySqlPool.lockConnection.




Ok, I read articles about pool, as I understood it's depend on of the
implementation. For example method `close` in pool mode should not close
connection, but return it to pool.



Calling 'close' will always close the connection. If you got you 
connection from the pool, then it will automatically return to the pool 
when you're no longer using it. No need to do anything special for that.



Could you tell about your implementation. Also actual question is can I
open connection in constructor (during class instance creation) ?


You can open a connection in a constructor if you wish. Or wherever you 
want to.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 04:33 AM, Suliman wrote:

ResultSet querySet(Connection conn, string sql, ColumnSpecialization[]
csa = null)

Could you explain last parameter?

`ColumnSpecialization[] csa = null`. I can't understand how to use it.



The vast majority of the time, you don't need to worry about that 
parameter, just omit it. It's just for if the fields you're pulling from 
the DB are very, very large and you want to handle the data as it comes 
in, rather than waiting for all the data to download. If you want to 
know more, it's in the documentation here:


http://semitwist.com/mysql-native-docs/v0.2.0-preview1/mysql/protocol/extra_types/ColumnSpecialization.html



Also I think it's better to remove old deprecated methods at all,
because it's add only mess.


They're still there for new just for backwards compatibility. But they 
are deprecated and will be removed in a later release.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 03:23 AM, Suliman wrote:

mydb.lockConnection() does create a new connection if it needs to. And
that WILL throw an exception if there's a problem connecting to the DB
server. So your code above WILL catch an exception if the connection
information (server address/port/login/etc) is wrong.


But it does not. I am getting Access Violation instead of the exception
if connection credentials is wrong:

Authentication failure: Access denied for user 'root'@'111.111.111.111'
(using password: YES)

object.Error@(0): Access Violation

0x004436C0 in void database.Database.connect() at
D:\code\CMS\source\database.d(34)
0x00403130 in _Dmain at D:\code\CMS\source\app.d(17)
0x00593C6F in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00593C33 in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00593B34 in _d_run_main
0x004433CC in main at D:\code\CMS\source\app.d(7)
0x005F0929 in mainCRTStartup
0x769262C4 in BaseThreadInitThunk
0x774D0FD9 in RtlSubscribeWnfStateChangeNotification
0x774D0FA4 in RtlSubscribeWnfStateChangeNotification
Program exited with code 1



I'm unable to reproduce this problem. Are you trying to use the 
connection after it fails to connect? It looks like that's what's 
happening, you're using a null reference.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 07:10 AM, aberba wrote:


* Moreover, how do I close a connection or does it auto close?



It closes in its destructor (although AIUI there are times when dtors 
don't get run). But it can be closed manually with Connection.close();



* Does it support mysql_real_escape_string() like in php? This factor-in
the db encoding to do he appriate encoding for '/\" ...


There is a function like that one that was contributed, 
mysql.escape.mysql_escape:


https://github.com/Abscissa/mysql-native-experimental/blob/master/source/mysql/escape.d#L4

But, it's better to use prepared statements, because then no escaping is 
needed, and there's no worry about forgetting to escape:


Prepared prepared = prepare(connection, "SELECT * FROM `someTable` WHERE 
i=? AND s=?");

prepared.setArgs(7, "hello");
ResultRange results = prepared.query();

The prepared statement is reference counted and will automatically be 
released when there are no references to it left.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 03:23 AM, Suliman wrote:

mydb.lockConnection() does create a new connection if it needs to. And
that WILL throw an exception if there's a problem connecting to the DB
server. So your code above WILL catch an exception if the connection
information (server address/port/login/etc) is wrong.


But it does not. I am getting Access Violation instead of the exception
if connection credentials is wrong:

Authentication failure: Access denied for user 'root'@'111.111.111.111'
(using password: YES)

object.Error@(0): Access Violation

0x004436C0 in void database.Database.connect() at
D:\code\CMS\source\database.d(34)
0x00403130 in _Dmain at D:\code\CMS\source\app.d(17)
0x00593C6F in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00593C33 in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00593B34 in _d_run_main
0x004433CC in main at D:\code\CMS\source\app.d(7)
0x005F0929 in mainCRTStartup
0x769262C4 in BaseThreadInitThunk
0x774D0FD9 in RtlSubscribeWnfStateChangeNotification
0x774D0FA4 in RtlSubscribeWnfStateChangeNotification
Program exited with code 1



Ahh, ok, that's a bug. Will fix.

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

Made a couple more long-needed changes while I'm at it:

https://github.com/Abscissa/mysql-native-experimental
Tag: v0.2.0-preview2

- For better clarity, renamed `mysql.db.MysqlDB` to `mysql.pool.MySqlPool`.

- Package mysql.connection no longer acts as a package.d, publicly 
importing other modules. To import all of mysql-native, use `import mysql;`

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 01:54 PM, Suliman wrote:

Also I can't understand what is SQL Command and what exec is doing if
it's returning ulong?




"struct Command" should not be used. It is old, and a bad design. This 
new release attempts to replace it with a better design. Hopefully, 
"struct Command" will be deleted in a later release.


The "exec" functions are for commands like INSERT, UPDATE, DELETE, 
CREATE, etc (it is *not* for SELECT). It is for things that do NOT 
return actual rows of data. The "exec" functions return "rows affected" 
- the number of rows that were affected by your INSERT, or UPDATE, etc. 
Usually people ignore that number, but it's information the server sends 
back, and is sometimes useful to some people. For example, SQL 
administration tools usually tell you "# rows affected" after you run an 
INSERT/UPDATE/etc.


If you are doing a SELECT, then you do NOT use "exec", you use "query" 
for SELECT. "query" returns a set of rows.


Summary:
-

SELECT: Use query() or querySet() or queryRow(), etc.

INSERT/UPDATE/DELETE/CREATE/DROP: Use exec(). Return value tells you how 
many rows were added/changed/deleted/etc.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 10:34 AM, Suliman wrote:

On Wednesday, 1 February 2017 at 14:06:39 UTC, Suliman wrote:

Am I right understand that Connection instance should created at
constructor and be one single for all class (and it will be reused by
fibers) or am I wrong?

If yes, where I should to close it? To put
scope(exit) c.close();

In destructor?

If yes, does it behavior should be same as for working in vibed pool
and without?


I'm not sure I understand the question here.

Whether you should use a vibed connection pool or not is completely up 
to you and your program. And the choice of when to create the 
connection, and when to close the connection, is also up to your own 
program's needs.


If you're using a connection pool, you shouldn't need to worry about 
closing the connection. The whole point is that the connections stay 
open until you need to use one again. When your program ends, then 
connections will close by themselves.




If I right understand class MysqlDB do not throw any exceptions, So I
can't understand how to handle wrong connection.

if(connection is null)
{
 try // useless
 {
 connection = mydb.lockConnection();
 }
 catch(Exception e)
 {
 writeln(e.msg);
 }
}


mydb.lockConnection() does create a new connection if it needs to. And 
that WILL throw an exception if there's a problem connecting to the DB 
server. So your code above WILL catch an exception if the connection 
information (server address/port/login/etc) is wrong.


Side note: That reminds me, I need to rename the MysqlDB class (and the 
mysql.db module). It's a connection pool (using vibe-d's connection 
pool), but their names make that very unclear.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 05:04 AM, Suliman wrote:

Plz update dub package on code.dlang.org


It's deliberately not in the main mysql-mative package just yet. I will 
put it there once people have a chance to try this, and it becomes clear 
there aren't any big problems with the redesign.


For now, this preview can be used like this:

$ git clone https://github.com/Abscissa/mysql-native-experimental.git
$ dub add-local mysql-native-experimental

And then, when you're doing using this preview:

$ dub remove-local mysql-native-experimental

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 01/30/2017 02:49 AM, Sönke Ludwig wrote:


What about directly going for 1.0.0? At least after it has gotten enough
real-world exposure, I'd say that the first API overhaul is a good
opportunity for that.


Good point.

mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

I've been working on a big refresh of mysql-native's API, to take care 
of various issues that have appeared with it. It involves some major 
breaking changes (although I've tried to keep old interfaces around for 
the moment, but marked deprecated), so I wanted to post it before 
committing to it so those interested have a change to take a look, give 
feedback, catch problems, etc.


Summary of these changes:

API overhauled for better safety, reliability and ease-of-use. 
Deprecated and replaced entire Command struct with better design. Better 
handling of null. Various bugs fixed and more rigorously tested.


--

For right now, the changes are in a separate fork, here:

https://github.com/Abscissa/mysql-native-experimental

The readme there has sample code and an overview of the new interface.

Changelog: 
https://github.com/Abscissa/mysql-native-experimental/blob/master/CHANGELOG.md


API ref: http://semitwist.com/mysql-native-docs/v0.2.0-preview1

---

So take a look, let me know if there's any big issues with it. If all 
looks good, this will soon be released as mysql-native v0.2.0.

Re: Dynamic Bindings to libui (x-platform GUI)

[Nick Sabalausky via Digitalmars-d-announce]

On 11/16/2016 03:50 AM, Kagamin wrote:

On Wednesday, 25 May 2016 at 16:47:30 UTC, Nick Sabalausky wrote:

Drives me nuts when people count "Always uses GTK on Linux" as "Native
UI". It's like those programs that do everything completely
Ubuntu-centric whenever possible and then advertise "Linux Support". I
*really* wish GTK would just die already.


https://github.com/andlabs/libui/pull/80


Yea, I spotted that. Looks nice, I hope it gets merged, but I'm not 
holding my breath:


- As its notes say, it is still incomplete

- The pull's author has stated (in discussion for #30) he doesn't intend 
to finish it


- Plus it's just been sitting unmerged since May

- The libui author himself still maintains he doesn't want Qt support 
and feels it's redundant since Qt exists (which makes me wonder what he 
feels the point of his own lib is in the first place, since, why use 
libui when Qt exists and can do native look on everything 
*including* GTK-based environments?). :(


Anyway, I'm glad there's D bindings for this, but I do wish the libui 
author would change his stance and allow a Qt backend, because that 
would make this a very attractive lib.


*Or* maybe GTK could just add support for Qt themes (without then 
removing the feature in a point release), but we all know that will 
never happen :/

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 11/11/2016 08:30 AM, Dicebot wrote:

On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:

Run the new dmd. If it fails, either fix your code or go temporarily
go back to the old dmd until you can fix your code.


D will never be considered production ready as pong as this attiude
remaind. Your described scenario in practice works like this:

- You decide to delay fix until you have time to investigate


I've gone through a lot of compiler upgrades on a lot of D projects, and 
in my experience, this "investigate and fix for the new dmd" has always 
been trivial (aside from one instance where Phobos's standard function 
deprecation policy wasn't followed).


Some things should certainly have a smooth transition path (like above, 
when replacing a Phobos function with a different one), but really, not 
everything needs to be.



- Half of users of your library you (or your colleagues) complain that
they can't upgrade their projects because you areso slow
- You desperately find time to do required fix which proves bavkwards
incompatible


AFAICT, That's not the case with this particular cycle detection matter.

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 11/11/2016 04:54 AM, Kagamin wrote:

On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote:

Only possibility is just to ignore ALL cycles, and print them if any
are detected.


Run the new detector and if it fails, run the old one, if it succeeds,
print a message.


Or:

Run the new dmd. If it fails, either fix your code or go temporarily go 
back to the old dmd until you can fix your code.

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 10/30/2016 09:27 PM, Martin Nowak wrote:


This is the release ships with the latest version of dub (v1.1.0),


Changelog for dub 1.1.0?

Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust

[Nick Sabalausky via Digitalmars-d-announce]

On 10/27/2016 02:43 AM, Sebastien Alaiwan wrote:


 From the article:

Surprise: C++ without optimizations is the fastest! A few other
surprises: Rust also seems quite competitive here. D starts out
comparatively slow."


These benchmarks seem to support the idea that it's not the parsing
which is slow, but the code generation phase. If code
generation/optimization is the bottleneck, a "ccache-for-D" ("dcache"?)
tool might be very beneficial.

(However, then why do C++ standard committee members believe that the
replacement of text-based #includes with C++ modules ("import") will
speed up the compilation by one order of magnitude?)



How many source files are used? If all the functions are always packed 
into one large source file, or just a small handful, then that would 
mean the tests are accidentally working around C++'s infamous #include 
slowdowns.

Re: mysql-native v0.1.7

[Nick Sabalausky via Digitalmars-d-announce]

On 10/21/2016 05:35 AM, Martin Tschierschke wrote:

On Thursday, 20 October 2016 at 21:25:50 UTC, Nick Sabalausky wrote:

Minor update to mysql-native: A client driver for MySQL/MariaDB
written natively in D from scratch via the published protocol specs,
with no dependency on the C MySQL client library. Supports either
Phobos or Vide.d sockets (works with or without Vibe.d).

https://github.com/mysql-d/mysql-native
DUB: http://code.dlang.org/packages/mysql-native

In v0.1.7:
- New: Test suite automatically tests with both Vibe and Phobos
sockets, not just Phobos. (@Abscissa)
- Change: Drop support for DMDFE 2.066.1 and below. Compiles on DMDFE
2.067.1 through 2.072.0.
- Fixed: Fix an import deprecation message for DMD 2.071. (@Abscissa)
- Fixed: #57: Added support for passing null parameters in prepared
statements by using Variant(null) (@machindertech)
- Fixed: #63/#69: Add escape module to package import (@Marenz)
- Fixed: #68: Update alias syntax (@Marenz)

Full changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

I know I've said docs and examples are a top priority for
mysql-native, but it's become clear that the API is in serious need of
a refresh, so for the most part, I've held off on the docs this time
to avoid wasted effort documenting to-be-deprecated interfaces.

Unless any pressing issues appear, expect the next release to be an
experimental branch showcasing a beta of a new API. If possible, I'd
like to have at least one release where the old API is still
functional, but deprecated.


Please consider to look at the APIs of the other mysql libs, maybe there
is one
which you can use. I found it easier to use the APIs of  mysql-d
(https://github.com/paxa/mysql.d) but mysql-lited
(https://github.com/eBookingServices/mysql-lited) looks more enhanced.


Hmm, actually, there appears to be a lot of similarity with part of what 
I had in mind:


https://github.com/mysql-d/mysql-native/issues/83

In particular, I *really* want to pretty much get rid of the Command 
struct. Minimizing heap activity is also a goal, albeit separate from 
this API refresh.



But here too:


Documentation is not ready yet


I would be very happy, if in the end there would be only one superior
mysql-lib for D, so
all can work together to improve this one.



mysql-native gets very few PRs. :(

mysql-native v0.1.7

[Nick Sabalausky via Digitalmars-d-announce]

Minor update to mysql-native: A client driver for MySQL/MariaDB written 
natively in D from scratch via the published protocol specs, with no 
dependency on the C MySQL client library. Supports either Phobos or 
Vide.d sockets (works with or without Vibe.d).


https://github.com/mysql-d/mysql-native
DUB: http://code.dlang.org/packages/mysql-native

In v0.1.7:
- New: Test suite automatically tests with both Vibe and Phobos sockets, 
not just Phobos. (@Abscissa)
- Change: Drop support for DMDFE 2.066.1 and below. Compiles on DMDFE 
2.067.1 through 2.072.0.

- Fixed: Fix an import deprecation message for DMD 2.071. (@Abscissa)
- Fixed: #57: Added support for passing null parameters in prepared 
statements by using Variant(null) (@machindertech)

- Fixed: #63/#69: Add escape module to package import (@Marenz)
- Fixed: #68: Update alias syntax (@Marenz)

Full changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

I know I've said docs and examples are a top priority for mysql-native, 
but it's become clear that the API is in serious need of a refresh, so 
for the most part, I've held off on the docs this time to avoid wasted 
effort documenting to-be-deprecated interfaces.


Unless any pressing issues appear, expect the next release to be an 
experimental branch showcasing a beta of a new API. If possible, I'd 
like to have at least one release where the old API is still functional, 
but deprecated.

Auto-gen list of D compiler versions: Improvements

[Nick Sabalausky via Digitalmars-d-announce]

The automatically-updated list of D compiler versions available on 
Travis-CI (and which front-end/back-end version they each use) has had a 
few small improvements lately:


http://semitwist.com/travis-d-compilers

- Now includes beta versions available for DMD (starting at v2.072.0) 
and LDC (starting at v1.1.0). GDC betas will automatically be supported 
if/when the "gdc-beta" label becomes available on travis.


- Fixed: Incorrectly parses LLVM version for LDC v1.0.0 and up

- Added links going directly to DMD/LDC/GDC sections. (No longer have to 
scroll through DMD entries to find LDC/GDC.)


- On-hover row highlighting.

As before, the list is currently set to automatically update once daily 
(although I can adjust that if need be. I just don't want to put an 
undue burden on travis by checking too often.)

SDLang-D v0.10.1 - Small bugfix

[Nick Sabalausky via Digitalmars-d-announce]

On 09/25/2016 06:12 PM, Nick Sabalausky wrote:

https://github.com/Abscissa/SDLang-D

New in v0.10.0:
Big convenience enhancements to DOM interface and an improved pull
parser interface. Plus documentation improvements and a couple bugfixes.

Full changelog:
https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md



Small bugfix update, v0.10.1, fixing one issue:

- Fix #50: Outputs certain floating point numbers in unsupported 
scientific notation.

https://github.com/Abscissa/SDLang-D/issues/50

Re: SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

On 09/27/2016 04:55 AM, Chris wrote:


I was actually thinking of using SDL for pseudo code non-programmers
could write, e.g. to create rule files that a program could execute. It
could work nicely with `if` and `else` tags + attributes.


A simple programming language that's SDLang-compliant would definitely 
be interesting!

Re: SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

On 09/25/2016 06:12 PM, Nick Sabalausky wrote:


-
// A few basic values
first "Joe"
last "Coder"
ip "127.0.0.1" port=80

// Supports child tags
folder "myFiles" color="yellow" protection=on {
 folder "my documents" {
 document "resume.pdf"
 }
}
-


Example of using some of the new API features:

-
import sdlang;

Tag root = parseFile("the-above.sdl");

string first = root.expectTagValue!string("first"); // Required
string last  = root.getTagValue!string("last"); // Optional

// Custom default values (if omitted, default value is T.init):
string ip = root.getTagValue!string("ip", "192.168.1.1");
int port = root.getTagAttribute!int("ip", "port", 8080);

Tag folder = root.expectTag("folder");
string folderName = folder.expectValue!string();
assert(folderName == "myFiles");
bool folderProtection = folder.getAttribute!bool("protection");

string subfolderName = folder.getTagValue!string("folder");
assert(subfolderName == "my documents");
-

SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

https://github.com/Abscissa/SDLang-D

New in v0.10.0:
Big convenience enhancements to DOM interface and an improved pull 
parser interface. Plus documentation improvements and a couple bugfixes.


Full changelog:
https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md

===

SDLang-D is a D library to read and write SDLang. Both a DOM and a Pull 
Parser are provided.


SDLang  is similar to XML/JSON/YAML, but much simpler 
and less verbose. It look like this:


-
// A few basic values
first "Joe"
last "Coder"
ip "127.0.0.1" port=80

// Supports child tags
folder "myFiles" color="yellow" protection=on {
folder "my documents" {
document "resume.pdf"
}
}
-
Language Guide: https://github.com/Abscissa/SDLang-D/wiki/Language-Guide

Re: mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

On 09/16/2016 02:41 PM, Rory McGuire via Digitalmars-d-announce wrote:

On 11 Sep 2016 16:57, "Nick Sabalausky via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:

[snip]
... a top priority for mysqln-native at this point.


Hi Nick is that a typo or are you working on a completely different
library? mysqln-native?



Typo. Sometimes mysql-native is referred to shorthand as "mysqln", so I 
guess my fingers just stuttered ;)

Re: mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

On 09/11/2016 07:02 AM, Emre Temelkuran wrote:

There is absolutely no proper documentation (only original's 2011 one).
This is why it's not popular.


Yea, I agree, it's an embarrassment. It's a top priority for 
mysqln-native at this point.

Re: DlangUI 0.9.0: Console backend added

[Nick Sabalausky via Digitalmars-d-announce]

On 09/09/2016 07:21 AM, Vadim Lopatin wrote:

Hello!

Now it's possible to build DlangUI apps to run in console (Linux, Windows).

Some screenshots (from dlangui example1 app):

   http://i63.tinypic.com/2wn1bg9.png
   http://i66.tinypic.com/142yctx.png
   http://i64.tinypic.com/snlc08.png
   http://i64.tinypic.com/2n16vcw.png



Very cool!

mysql-native v0.1.6

[Nick Sabalausky via Digitalmars-d-announce]

Another small update, v0.1.6, to fix this: Linker error when using dub 
to import *just* vibe-d:core, but not all of vibe.d.


At least once code.dlang.org notices the new tag.

mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

Tagged a new release of mysql-native: A client driver for MySQL/MariaDB 
written natively in D from scratch via the published protocol specs, 
with no dependency on the C MySQL client library. Supports either Phobos 
or Vide.d sockets (works with or without Vibe.d).


Despite the seemingly low version number, this library is used in 
real-world projects by various people and has been around (with various 
maintainers and contributors) since Steve Teale's original release in 2011.


In this version:
- New: #73: Integration testing via travis-ci. (@Abscissa)
- New: Started this changelog. (@Abscissa)
- Fixed: #20: Contract failure in consume!string (@Marenz)
- Fixed: #50: bindParameters example was wrong (@Abscissa)
- Fixed: #67: Fix unittest for escape (@Marenz)
- Fixed: #70: Check for errors where we expect the greeting packet (@Marenz)
- Fixed: #78: Use vibe-d sub package dependency and a more current 
version (@s-ludwig)
- Fixed: #79: Dub fetch all vibe-d dependencies, even if there is no 
reason (@s-ludwig)


Full changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

Future direction:
Priorities need to be a published API documentation and some good docs, 
plus continue addressing the existing issues/PRs.


Github Homepage: https://github.com/mysql-d/mysql-native
On DUB: http://code.dlang.org/packages/mysql-native

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/25/2016 06:37 PM, Chris Wright wrote:

On Tue, 23 Aug 2016 12:19:12 -0400, Nick Sabalausky wrote:

Couple very minor updates:


Please, for the love of potatoes, tell people what the project is for!



Oops, right, I did forget that this time, didn't I. Posted too hastily!

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/24/2016 11:16 AM, Martin Nowak wrote:

On Tuesday, 23 August 2016 at 16:19:12 UTC, Nick Sabalausky wrote:


gen-package-version v1.0.4:


What's your stance on including that functionality into dub?


I have nothing against it, I think it would be a fine optional feature 
for dub. I won't be putting together a PR for it though, and I don't 
think there's all that much of a need for it since gen-package-version 
already exists and works AND doesn't require dub to be used as a 
project's build system.


(As much as I love dub for package management, and having the *option* 
of using dub as a build system, dub's built-in build system just isn't 
always the best fit for all projects. Pet peeve: I still find it very 
problematic that there's really no good way to tell dub "don't attempt 
to build this project yourself as this project uses a different build 
system, so just run the following command INSTEAD of directly attempting 
to build". I've tried to fool it into not actually doing the build 
itself, but it's quite messy and problematic. It claims to be usable as 
a package-manager-only, but realistically, that's still only true for 
top-level projects that are never, ever used as a dependency, and not 
for library projects or tools that other projects may wish to rely on.)

Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

Couple very minor updates:

gen-package-version v1.0.4:
-
Updated docs to include dub.sdl samples, not just dub.json.

https://github.com/Abscissa/gen-package-version


sdlang-d v0.9.6:
-
Issue #39: Remove references to deprecated module std.stream (@lesderid)

https://github.com/Abscissa/SDLang-D

I'm hoping to finally get around to taking care of some of the open 
enhancement requests for sdlang-d soon.

Re: QtE5 - is a wrapping of Qt-5 for D

[Nick Sabalausky via Digitalmars-d-announce]

On 06/20/2016 12:52 PM, MGW wrote:

This my library has about 400 functions from Qt and is quite efficient
for small applications.



Ooh, awesome, this is something D really needs! Definitely going to have 
to give this a try.

Re: Beta release DUB 1.0.0-beta.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/13/2016 07:31 AM, Kagamin wrote:

On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting comment
blocks are a worthless PITA with no real benefit: You can't comment
out a block if the block already contains a block comment.


Block comments are low-level: the commented code changes its lexical
structure completely, but you probably don't expect it and want it to
behave and be properly commented at a higher level, which is provided by
version statement.


No, I WANT commenting-out to be low-level, but just not have a stupid, 
useless, badly-chosen rule for when the block ends.


Version(none) is too high-level. I can't use it *within* a statement, 
which means I'd have to use one method to "comment-out" blocks of code 
and a different method when I comment out ex., params, args, or parts of 
an expression (all of which I occasionally do). But why would I want to 
do that when there's one construct (nesting block comments) that works 
perfectly for both AND actually gets highlighted as "disabled" in every 
editor and HTML highlighter out there so I can actually see at a glance 
what's disabled?

Re: Beta release DUB 1.0.0-beta.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting comment 
blocks are a worthless PITA with no real benefit: You can't comment out 
a block if the block already contains a block comment. You can't include 
a block comment inside documentation's sample code. All for...why?


The only real reason is C-compatibility, which I don't see much of a 
benefit in either - if you're porting C code to D that actually *relies* 
on the goofy behavior of /* */, then the C code's comments are a 
terrible mess and need fixing anyway.


I wish we could just abolish non-nesting comment syntax entirely.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 06/07/2016 12:05 PM, FreeSlave wrote:

On Tuesday, 26 April 2016 at 06:42:11 UTC, Nick Sabalausky wrote:

https://semitwist.com/travis-d-compilers

That's an auto-generated listing of all versions of DMD, GDC and LDC
available on travis-ci.

[...]


Looks like semitwist.com is down.


Oops. It's back up now.


How about duplicating this list to
github pages?


Not a bad idea.

https://github.com/Abscissa/travis-dc-detect-master/issues/4

Scriptlike v0.9.6 - Minor update

[Nick Sabalausky via Digitalmars-d-announce]

This is a minor update to Scriptlike: A utility library to help you 
write script-like programs in D.


- Fixed deprecation warnings with DMD 2.070.x and 2.071.0
- Fixes the Travis-CI build which had been a little bit borked.
- Interact module properly flushes stdout when prompting for user input 
[by Jesse Phillips]


More details in the changelog:
http://semitwist.com/scriptlike/changelog.html

Main site and docs:
https://github.com/Abscissa/scriptlike

On dub:
http://code.dlang.org/packages/scriptlike

Re: IDE - Coedit 2, update 6 released

[Nick Sabalausky via Digitalmars-d-announce]

Also, just a minor wishlist thing, but it'd be nice if the currently 
active file (or project name, or something) was prepended to the 
window's title bar, so it's displays on people's taskbar. That comes in 
handy when using multiple editor windows.

Re: IDE - Coedit 2, update 6 released

[Nick Sabalausky via Digitalmars-d-announce]

On 05/28/2016 09:08 AM, Basile B. wrote:

On Friday, 27 May 2016 at 17:49:18 UTC, Bauss wrote:

On Thursday, 26 May 2016 at 23:44:21 UTC, Basile B. wrote:

Mostly because an important feature of the library manager was not
compatible with DUB > v0.9.24. Otherwise almost nothing.

See https://github.com/BBasile/Coedit/releases/tag/2_update_6 for the
changelog and the binaries.


Is there anyway to get dark theme?


If the native UI of the operating system has a dark theme then Coedit
will have a dark theme too. You just have to adjust the highlighter
attributes, like here:

http://imgur.com/sKCB1Vz


It'd be nice if there was a pre-defined set of dark highlighter 
attributes that could just be selected and then used out-of-the-box or 
as a starting point. In general, manually adjusting editor themes can 
get to be a pain, especially when the color settings are mixed in with 
the rest of the settings.


Seems like a really nice editor though, I just tried it for the first 
time right now. I'd been having a hard time finding an editor I really 
like since switching my main dev machine to Linux (previously had been a 
die-hard Programmer's Notepad 2 user, but it has some issues under wine, 
and of course it doesn't do DCD). Hopefully this one will fit the bill, 
looks nice so far.


Few newbie questions:

- In other editors, I tend to rely very heavily on "Ctrl-Tab" to switch 
between opened files (in most-recently-used order - analogous to Alt-Tab 
in many desktop environments). Is there an entry for that in 
"Options"->"Shortcuts"->"Code editor" so I can set that up? I didn't 
spot one at a glance, but I could've easily overlooked it.


- Regarding "tab vs space" indents, the boolean options eoSpacesToTabs, 
eoTabsToSpaces, and eoTabIndent seem key, but I'm a little unclear on 
exactly how they work, and the "options1"/"options2" in general don't 
appear to be documented (understandable, given how many there are, which 
is nice though, I like configurability. Adjusting software to fit people 
is much better than adjusting people to fit software, and 
"one-size-fits-all" only ever works for hats :) ).


- Mostly wishful thinking but I don't suppose there are any plans for 
elastic tabstops, are there?


- Not an objection really (and I'm sure this has been asked before, so 
pardon that), but I'm curious why it's written in Pascal rather than D. 
Lack of good-enough GUI libs for D? Any plans to port to D down the 
road? It'd likely be easier to get contributors if it were in D, but I 
imagine you probably already figured that. Not trying to push for 
porting of course, I'm just curious.


- I am getting a little bit a weird behavior in a couple places (This is 
on Debian x64, KDE4, FWIW):


When I type 'm' in the editor (without Shift), I get a newline instead 
of an 'm'. The other letters appear to work fine.


Also, in the options editor and the search/replace text box (maybe other 
places as well?), anything I type gets doubled. For example, if I try to 
type in a value of "20", I get "2200". "if" becomes "iiff". Backspace 
works fine, so I can easily erase the extra characters, but something 
seems to have gone weird there.


And the "Find" button doesn't appear to successfully find things even 
when they are there. "Find All" works though.


- It'd be nice if there was a way (if there isn't already?) to set up 
Ctrl-F (or something) to automatically jump to and select the text in 
the "Search" entry box.

Re: Dynamic Bindings to libui (x-platform GUI)

[Nick Sabalausky via Digitalmars-d-announce]

On 05/24/2016 04:52 PM, extrawurst wrote:


So here are the inofficial Derelict Bindings to it:
https://github.com/Extrawurst/DerelictLibui



Some D-oriented docs and example code would be nice.

>
> find libui on github:
> https://github.com/andlabs/libui

Hmm:

> uses the native GUI technologies of each platform it supports
> ...
> Windows: Windows Vista SP2 with Platform Update or newer
> Unix: GTK+ 3.4 or newer
> Mac OS X: OS X 10.7 or newer

Drives me nuts when people count "Always uses GTK on Linux" as "Native 
UI". It's like those programs that do everything completely 
Ubuntu-centric whenever possible and then advertise "Linux Support". I 
*really* wish GTK would just die already.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 05/07/2016 05:44 AM, Johan Engelen wrote:

What I mean is: currently the Name column says e.g. "ldc2-0.17.1", but
in the travis.yml file you must specify "ldc-0.17.1" to get it (without
the "2").


Ahh, you're right, I hadn't noticed that.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 04/28/2016 04:03 PM, Seb wrote:


FYI you miss the available ldc alpha and betas. On purpose?


Didn't initially occur to me, but I'd say that's a "possible future 
enhancement". It will take more work, and some extra thought, to figure 
out how to handle:


Right now, my tool relies on the ability to say in .travis.yml "just 
give me the latest available version" (by saying, ex "dmd" instead of 
"dmd-2.070.0"). Then my tool checks which version that turned out to be 
and posts it. I'm not aware of an equivalent that includes alpha/beta 
releases. I wonder if it would be easy enough for the folks handling D 
on travis to add? That would be the easiest way for me.


I *could* manually trigger it for each alpha/beta *already* available 
(like I did to initially populate the database with all the earlier 
versions of everything). I guess that would be information worth 
archiving. But that still doesn't give me a way to capture new 
alphas/betas automatically. Hmm, I do have an idea for how to do that, 
but it may be a little convoluted so I'd have to get to it later.


I guess...we'll see ;)

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 04/26/2016 02:42 AM, Nick Sabalausky wrote:

https://semitwist.com/travis-d-compilers

...

- Auto-trigger an update check on a regular basis (I'm thinking once
daily?) so I don't have to stay on top of new compiler versions and
trigger an update manually. (I can use Travis's API to do this.)



The page is now set to automatically check for updates every 24 hours. 
So it should always be automatically up-to-date now. No intervention 
needed by myself or any of the DMD/LDC/GDC developers.

Re: Argon: an alternative parser for command-line arguments

[Nick Sabalausky via Digitalmars-d-announce]

On 03/02/2016 02:50 PM, Markus Laker wrote:

https://github.com/markuslaker/Argon

Let me know if you do something interesting with it.

Markus



Reminds me of one I used years ago for C#: I like the approach, it's a 
good one. Getopt by comparison, while very good, always seemed like a 
kludge to accomplish a similar thing without the benefit of user 
attributes (which D lacked at the time).

Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration

[Nick Sabalausky via Digitalmars-d-announce]

On 02/03/2016 02:33 PM, H. S. Teoh via Digitalmars-d-announce wrote:

On Wed, Feb 03, 2016 at 07:25:55PM +0200, Dicebot via Digitalmars-d-announce 
wrote:


The problem is how you are going to expose templated stuff which
dominates most useful D libraries.


This is certainly an interesting idea worth exploring, and certainly
doable for plain ABI interop, as Dicebot says.

For templates... I dunno, some stuff is probably untranslatable, or at
least, can't be translated into a form that's suitable for end-users,
like alias parameters, variadics, tuple/AliasSeq shenanigans, etc.. But
some of the simpler stuff might be doable.

Perhaps... this is a crazy idea that just occurred to me -- write a D to
C++ template syntax translator?


Well, I don't think it's worth (at least short term anyway) getting too 
caught up in the idea of more advanced stuff like that, and equivalent 
template semantics and such, being usable from the C/C++ side of an 
interface.


Much of the time, the bulk of a lib's use-cases can be exposed via 
simple wrappers that expose a simplified API. Naturally, this wouldn't 
be as nice as benefiting from D's full feature set, but if you're not 
writing *in* D then you're kind of forgoing a lot of those niceties anyway.


Longer term, maybe more tricks could be devised to offer more benefits 
to a D lib's C/C++ users. Or maybe not. But either way, that's not 
really the important part. The important part is just straightforward 
out-of-the-box access to a D lib's main use-cases, rather than 
reproducing as much of the D experience as possible.


Perhaps I was overstating a bit saying "every" D library. Naturally, 
some libs will make more or less sense to use from C/C++ than others. 
But with just a little thought given to "What is this lib's MAIN 
purpose? What are the IMPORTANT features that could be wrapped up in a 
simpler C-accessible API, verses merely D niceties that aren't necessary 
for C/C++ users to gain usefulness from this lib?" With just a little 
thought given to that, I think we could offer some actual usefulness to 
C/C++ users, which simultaneously benefits them and helps our street cred.


Of course I'm not saying D libs should jettison D niceties for the sake 
of C/C++ compatibility. But just offer whatever C/C++-sensible subset 
they reasonably can to the C/C++ world.


From the C/C++ perspective, think of it like exposing a C/C++ library 
with "the core of this is written in D" as an implementation detail. Of 
course, actual D programs would get even MORE benefit from the lib, by 
bypassing the "funneling this into C/C++-compatible form" layer.

Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration

[Nick Sabalausky via Digitalmars-d-announce]

On 02/03/2016 12:25 PM, Dicebot wrote:

On 02/03/2016 07:05 PM, Nick Sabalausky wrote:

Something that's been on my mind for a few months, finally got around to
a little write-up about it.

We're Overlooking A Key Part of C/C++ to D User Migration:

https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration


For plain ABI interop it is actually something that should be doable by
compiler as part of .di header generation - generate matching
`extern(C)` wrappers for non-templated code (expanding all arrays to ptr
+ len pairs etc.).

The problem is how you are going to expose templated stuff which
dominates most useful D libraries.



I expect that in many, if not all cases, the library's FULL power and 
benefits might realistically only be accessible to D. But usually, some 
simple wrappers on the D side should be plenty to expose the primary 
use-cases to C. In particular, specially-selected pre-instantiations and 
simple convenience wrappers can go a long way.


For example, an XML library in D: This would likely be heavily templated 
to operate on ranges for everything. But usually, the lib's end users 
are only going to need UTF-8 strings, maybe UTF-16. The C users 
especially aren't likely to need more than that. So pre-instantiating 
for string and maybe wstring, wrapped up in non-templated wrappers would 
be perfectly sufficient to be useful to C users.


Or a regex lib: Compile-time regex (like ctRegex in phobos) would be out 
of the question, but the run-time version could still be exposed and 
useful. (Or, if the lib author *really* wanted to get clever and impress 
the C side, they could offer a simple CLI tool to pre-compile a regex 
outputting a D module and/or C header, which C programs could link in. 
But regardless, even just limiting C-land to the runtime version would 
still be offering something useful.)

Re: Better docs for D (WIP)

[Nick Sabalausky via Digitalmars-d-announce]

On 12/30/2015 08:32 PM, Adam D. Ruppe wrote:

It was rejected. Walter didn't see what the problem was and I was told
to just write $(LT)span$(GT)foo$(LT)/span$(GT). Seriously.


[...]


The idea (and working program) was rejected because the team felt a
post-processor was the wrong way to do it.


That's been quite possibly THE biggest thorn in my side discouraging me 
from contributions. I've seen, and personally run into, plenty of cases 
where a non-existent ideal implementation becomes the mortal enemy of 
progress that already exists. I could ramble off a whole list of cases.


It's sooo much easier to just do my own thing and "get it done" than 
waste effort on politics and playing the "is this worthwhile?" game with 
people who prefer wasting their time defending stagnation over stepping 
back and allowing others to just get problems fixed, even if not in an 
perfectly ideal way.


I'll take a temporarily imperfect solution over vaporware ideals any day.

Re: Release D 2.070.0

[Nick Sabalausky via Digitalmars-d-announce]

On 01/29/2016 11:09 AM, Adam D. Ruppe wrote:

On Thursday, 28 January 2016 at 19:46:48 UTC, Nick Sabalausky wrote:

Use dpldocs.info. We have good docs.


That's orthogonal to this.


It is just another example of why I feel it is necessary to take a
different direction than dmd.


I see. Good point. You've probably answered this elsewhere, but I don't 
recall: Does that parse the source for comments on its own or does it 
still use dmd's json (or html) output? Unless it does the parsing 100% 
on its own, then it would still suffer from the issue that PR addresses.

Re: Release D 2.070.0

[Nick Sabalausky via Digitalmars-d-announce]

On 01/29/2016 12:53 PM, Adam D. Ruppe wrote:

On Friday, 29 January 2016 at 17:49:58 UTC, Nick Sabalausky wrote:

I don't recall: Does that parse the source for comments on its own or
does it still use dmd's json (or html) output?


Does it on its own. (Well, except the search results page, it still uses
the json, but I'm fixing that soon and the main body pages already do
their own thing.)

Brian Schott's libdparse does the bulk of the work, independently of
dmd. A big reason for this is that doing changes on dmd is a pain in the
butt, and another one is that dmd is optimized toward compiling code (as
it should be!) which isn't always ideal for doc generation (like
version(Windows) docs being left out if you happen to be on a Linux box.)

So doing it myself frees me from dmd's design constraints as well as
dmd's development process.



Ah, cool. I've filed this: 
https://github.com/Hackerpilot/Dscanner/issues/304

Re: Release D 2.070.0

[Nick Sabalausky via Digitalmars-d-announce]

On 01/28/2016 12:29 PM, Adam D. Ruppe wrote:

On Thursday, 28 January 2016 at 15:17:26 UTC, Nick Sabalausky wrote:

This one is still MIA after all this time:
https://github.com/D-Programming-Language/dmd/pull/4745


Use dpldocs.info. We have good docs.


That's orthogonal to this.

Re: Release D 2.070.0

[Nick Sabalausky via Digitalmars-d-announce]

On 01/27/2016 04:08 PM, Martin Nowak wrote:

Glad to announce D 2.070.0

http://dlang.org/download.html

This release comes with the new std.experimental.ndslice, heavily
expanded Windows bindings, and native exception handling on 64-bit linux.
See the changelog for more details.

http://dlang.org/changelog/2.070.0.html

-Martin




This one is still MIA after all this time: 
https://github.com/D-Programming-Language/dmd/pull/4745

Re: DConf 2016 news: 20% sold out, book signing

[Nick Sabalausky via Digitalmars-d-announce]

On 12/12/2015 01:13 AM, Joakim wrote:


Desktop Android's certainly not there yet for everybody, but it is for
my admittedly low demands, and soon will be for everybody, as google has
said they're working on built-in multi-window for the next version of
Android.


Personally, I would need far more than just multi-window support for 
Android to be a worthwhile desktop OS for me. A lot of the issues 
(though not nearly all) relate to software ecosystem.


For example, I can't even find a halfway decent alternative to windows 
notepad, let alone any better text editor. Basic undo/redo support is 
rare in Android software, as is saving/loading actual files and sharing 
user files between different programs on the same machine, which is 
something desktops had pretty much sorted out decades ago.


The whole backup/restore situation is a mess (there's an article that 
explains my issues with it better than I can, but my link to it is 
buried somewhere ATM), PalmOS already had backup/restore sorted out much 
better over a decade ago. Heck, even same with iOS if you can tolerate 
iTunes and, well, Apple/iOS.


That's just a few off-the-top-of-my-head examples. There's many others, 
like the bluetooth keyboard lag/unresponsiveness that you've already 
mentioned, and I can confirm from experience.

Re: The D Language Foundation is now incorporated

[Nick Sabalausky via Digitalmars-d-announce]

On 10/19/2015 10:49 AM, Jacob Carlborg wrote:

On 2015-10-19 13:18, Russel Winder via Digitalmars-d-announce wrote:


Has anyone tried GitLab (was Gitorious)?


Yes, we're using at work. It's what you use if you don't want to pay for
GitHub :). I think it's really good, almost as good as GitHub.



From what I've seen, I think it's better than GitHub. Although I 
haven't really used it for an actual project yet.

Re: Fastest JSON parser in the world is a D project

[Nick Sabalausky via Digitalmars-d-announce]

On 10/16/2015 08:53 AM, Steven Schveighoffer wrote:

On 10/16/15 6:20 AM, Ola Fosheim Grøstad wrote:

On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote:

On Thursday, October 15, 2015 14:51:58 Johannes Pfau via
Digitalmars-d-announce wrote:

BTW: Is there a reason why the code is GPL licensed? I understand
that people might want to use more restrictive licenses, but isn't
LGPL a better replacement for GPL when writing library code? Doesn't
the GPL force everybody _using_ fast.json to also use the GPL license?

See: http://stackoverflow.com/a/10179181/471401


I think that you might be able to link code with various other
compatible, open source licenses against it, but you definitely can't
link any proprietary code aganist it.


Yes, you can. GPL only affects distribution of executables to third
party, it doesn't affect services. Maybe you are thinking of AGPL, which
also affects services. But even AGPL allows internal usage.



No, you cannot link against GPL library without making your code also
GPL. "Services" I don't think have anything to do with this, we are
talking about binary linking.



This is the real reason I'm not a huge fan of *GPL. Nobody can 
understand it!

Re: Beta D 2.069.0-b1

[Nick Sabalausky via Digitalmars-d-announce]

On 10/07/2015 06:33 PM, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.069.0.html

Please report any bugs at https://issues.dlang.org

-Martin



Can we please get this one in?:

https://github.com/D-Programming-Language/dmd/pull/4745

I'm getting tired of watching, updating and rebasing it, and also tired 
of the paragraphs in my generated docs being all messed up.

Re: This Week in D: livestreaming and we're moving forward on Windows bindings!

[Nick Sabalausky via Digitalmars-d-announce]

On 10/05/2015 05:30 PM, Andy Smith wrote:

On Monday, 5 October 2015 at 19:35:53 UTC, anonymous wrote:

On Monday 05 October 2015 21:29, Adam D.  Ruppe wrote:

which generates Microsoft format object files and the MS linker even
on 32

bit

I think you a word there.



I think you a grammatical error there.



Yea, I hate when I accidentally a word. At least he didn't accidentally 
all the words, and be in the same boat as this poor fella: 
https://answers.yahoo.com/question/index?qid=2021143759AAw9rUQ

Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 08:42 PM, Meta wrote:


What about even just removing the syntax distinction between string
mixins and template mixins?

mixin "int i = 0";
mixin declareI!();



I like that idea. It it feasible? I'd always assumed the syntaxes were 
different because they needed to be for some sort of technical reason. 
But now that I look at it...maybe that could work after all?

Re: DUB 0.9.24 release

[Nick Sabalausky via Digitalmars-d-announce]

On 09/24/2015 07:23 AM, Suliman wrote:

btw, yaml is still looks for me more readable and easier to googling.


Yaml is a very complicated format.

Re: DUB 0.9.24 release

[Nick Sabalausky via Digitalmars-d-announce]

On 09/24/2015 09:45 AM, Chris wrote:

On Sunday, 20 September 2015 at 19:36:13 UTC, Sönke Ludwig wrote:

http://sdl.ikayzo.org/ does not work atm.



Permanent mirror here:

http://semitwist.com/sdl-mirror/Home.html

> Is there a tool/switch that converts my old dub.json files to dub.sdl?

Not at the moment. But the SDLang-D project *does* need to add some 
conversion tools. I don't know that I can get to it right away though.

Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 01:44 AM, Sönke Ludwig wrote:


An alternative idea would be to mix in a local "writeln" function, which
can then be used multiple times without syntax overhead:

mixin template interp()
{
 void iwriteln(string str)()
 {
 // pretend that we actually parse the string ;)
 write("This is ");
 write(somevar);
 writeln(".");
 }
}

void main()
{
 int somevar = 42;
 mixin interp;
 iwriteln!("This is ${somevar}.");
}



Hmm, interesting idea. I'd leave it as a string-returning function, 
rather than automatically printing, but a writeln convenience wrapper is 
a nice idea too.


The one problem I'm seeing with it though, is it wouldn't be able to see 
symbols declared between the "mixin interp;" and any later uses of it. Ie:


void main()
{
int somevar = 42;
mixin interp;
iwriteln!("This is ${somevar}.");

int another = 17;
iwriteln!("This won't work, using ${another}.");
}

Seems like it would be too awkward and confusing to be worthwhile. :(

Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 02:21 AM, Jacob Carlborg wrote:


Different bikeshedding: I would prefer to make the curly braces optional
if it only contains a symbol.



I agree. I've left that as a future enhancement for the right now. 
Although it shouldn't be too difficult a change. Filing it here:


https://github.com/Abscissa/scriptlike/issues/23

Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 02:30 AM, Jacob Carlborg wrote:

On 2015-09-22 22:18, Nick Sabalausky wrote:

Big update to Scriptlike, v0.9.4:
https://github.com/Abscissa/scriptlike

Scriptlike is a library to help you write script-like programs in D.


One thing that really bugs me in Phobos, Scriptlike seems to have the
same problem, is that there are three (!!!) different functions to
remove something from the file system. Give me just one function that
removes everything, regardless if it's a file, directory and if it's
empty or not.



Me too. That's why this latest version adds removePath and 
tryRemovePath, which do exactly that ;)


http://semitwist.com/scriptlike-docs/v0.9.4/scriptlike/file/extras/removePath.html

http://semitwist.com/scriptlike-docs/v0.9.4/scriptlike/file/extras/tryRemovePath.html

(Pardon the excess paragraph breaks on those pages. *cough* 
https://github.com/D-Programming-Language/dmd/pull/4745 *cough*)


Of course, that does mean two *more* functions, but at least they're the 
only ones you need. :)

Re: OneDrive Client written in D

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 08:38 AM, Rory McGuire via Digitalmars-d-announce wrote:

Problem is right now anyone can make an app and pretend its your app, and
then ...

If the user gives your keys access to their stuff so does anyone else who
has your keys, if they can get the oauth2 redirect to redirect to a
matching url at least.



Isn't oauth/openid just kindof a big bundle of such phishing problems 
anyway?

Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

On 09/23/2015 03:18 PM, Chad Joan wrote:


This is why I argued for alternative mixin syntax in D some ... years?
... ago.

It'd be really cool to have a writefln overload that did this:

int somevar = 42;
writefln#("This is ${somevar}");

writefln#("Plus two and you get ${somevar+1}");

Which would just be shorthand for

int somevar = 42;
mixin writefln!("This is ${somevar}");

mixin writefln!("Plus two and you get ${somevar+2}");


I feel like a bit of syntax sugar could go a long way ;)


Yea, the trouble with string mixins is that they're ugly enough people 
don't like to use them.


I'd argued in the past for a way to tag a CTFE-able string-returning 
function as being intended for mixing-in, so you could omit the 
"mixin(...)" part. But we only ever got it for template mixins. Allowing 
it for string mixins was too controversial. :(


I dunno, maybe even a string mixin sugar as simple as this would be a 
big help:


mixin!func(args to func here)

ie:

mixin!interp("Some string here")

But I'm guessing the ship's ling since sailed for anything like that.

Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

[Nick Sabalausky via Digitalmars-d-announce]

Big update to Scriptlike, v0.9.4:
https://github.com/Abscissa/scriptlike

Scriptlike is a library to help you write script-like programs in D.

The two highlights in this release are string interpolation and a full 
set of examples in the documentation. Also of note are the new functions 
removePath and tryRemovePath which can be used to delete files (like 
remove) *or* directories (like rmdirRecurse).


Full changelog:
http://semitwist.com/scriptlike/changelog.html

=
String Interpolation:
=
https://github.com/Abscissa/scriptlike#string-interpolation

AFAICT, a string mixin is necessary to accomplish this in D, but 
otherwise it works much like other languages:



// Output: The number 21 doubled is 42!
int num = 21;
writeln(
mixin(interp!"The number ${num} doubled is ${num * 2}!")
);


The interpolated sections are handled via std.conv.text(), so they 
accept any type.


Bikeshedding requested! I'm not 100% sold on the name "interp" for this 
long-term. Suggestions welcome.


=
Examples:
=
https://github.com/Abscissa/scriptlike
https://github.com/Abscissa/scriptlike/blob/master/USAGE.md
https://github.com/Abscissa/scriptlike/tree/master/examples

The homepage/readme now provides sample code demonstrating all of 
Scriptlike's various features.


The second link above demonstrates suggested practices for how to use 
Scriptlike in a D-based script.


And finally, all examples are included as actual runnable programs (all 
automatically tested by "dub test", to ensure continued freshness).


==
All changes in v0.9.4:
==
- Fixed: Previous release broke the unittest script when dub test 
support was added.


- Fixed: In echo mode, several functions would echo the wrong "try*" or 
non-"try*" version. Ex: run echoed tryRun, and tryRename echoed rename.


- Fixed: Path and buildNormalizedPathFixed now convert back/forward 
slashes to native on BOTH Windows and Posix, not just on Windows.


- Fixed: Some links within changelog and API reference were pointing to 
the reference docs for Scriptlike's latest version, instead of staying 
within the same documentation version. This made archived docs for 
previous versions difficult to navigate.


- Enhancement: #17,#20: Added usage examples to readme.

- Enhancement: Add interp for interpolated strings:
string s = mixin( interp!"Value is ${variableOrExpression}" )

- Enhancement: Add removePath/tryRemovePath for deleting a path 
regardless of whether it's a file or directory. (Calls remove for files 
and rmdirRecurse for directories.)


- Enhancement: Add a Path-accepting overload of escapeShellArg for the 
sake of generic code.


- Enhancement: When runCollect throws, the ErrorLevelException now 
includes and displays the command's output (otherwise there'd be no way 
to inspect the command's output for diagnostic purposes).


- Enhancement: Greatly extended and improved set of tests.

Re: Release D 2.068.1

[Nick Sabalausky via Digitalmars-d-announce]

On 09/19/2015 07:51 PM, Vladimir Panteleev wrote:


What would DMD identify itself as then, if a version is not specified on
make's command line?


It could use the output of `git describe`.

That would probably be better anyway, because non-release builds would 
properly identify themselves as non-release builds with both the most 
recent tag name AND, if local HEAD isn't tagged, it will also include 
the git commit hash (and, IIRC, the number of commits since the most 
recent tag). *Much* better than having two months of master commits all 
identifying as the exact same version.


 gen-package-version[1] operates on exactly that 
strategy (which I learned about from dub's source).


[1] https://github.com/Abscissa/gen-package-version

Re: Build It And They Will Not Come

[Nick Sabalausky via Digitalmars-d-announce]

On 09/11/2015 01:59 PM, Bill Baxter via Digitalmars-d-announce wrote:

To be fair, wasn't the movie talking about dead baseball player ghosts
coming? For people to take that example and apply it to other endeavors in
life is a bit ridiculous.



That's pretty similar to how I felt about Doom3: People complained how 
"unrealistic" it was to not be able to duct tape the flashlight to the 
gun, but...For crap's sake, it's a game about a demon invasion from hell 
and one guy single-handedly holding them all off. Realism and 
believability were obviously never the point. :)


'Course, that game had other issues, but realism (or lack of) was never 
one of them.



But maybe I'm misremembering. Saw it a long time ago.


Never saw it myself, but that's what I'd heard it was about.

Re: 1st Ever Artificial Consciousness to be Written in D Language

[Nick Sabalausky via Digitalmars-d-announce]

On 09/02/2015 11:27 AM, Enamex wrote:


Free will and consciousness?

... Not to be a jerk, but I thought we hadn't settled these problems yet
as they apply to already existing sapient beings, which just happen to
be us. I'm more amused than skeptical, to be honest, given the release
date for a 'demonstration' if it's supposed to have even half of that
list even 1/10th implemented.


My thoughts exactly.

Reminds me of a (print) article I came across one time. It was about the 
idea of AI consciousness, but the whole article was based on one hell of 
a gigantic assumption: That consciousness is a natural consequence of a 
sufficiently large neural net. It's a fine and interesting idea, but 
PURELY speculative, with zero evidence and not even any way of testing 
for evidence since, like you say, we can't even figure out the first 
thing about consciousness as it relates to ourselves and each other, let 
alone to machines.

Re: Moving forward with work on the D language and foundation

[Nick Sabalausky via Digitalmars-d-announce]

On 08/28/2015 02:59 PM, bachmeier wrote:

On Friday, 28 August 2015 at 17:52:43 UTC, Nhale wrote:

good luck focusing on the D.


downvote


The D jokes almost make me miss the C++? You should be using A++! 
Durr hurr hurr jokes from non-programmers who thought they were being 
original and clever.


Almost.

Re: D-Day for DMD is today!

[Nick Sabalausky via Digitalmars-d-announce]

On 08/23/2015 01:17 AM, Walter Bright wrote:


We have made the switch from C++ DMD to D DMD!



http://semitwist.com/download/av/you-did-it.mp4

Re: D-Day for DMD is today!

[Nick Sabalausky via Digitalmars-d-announce]

On 08/23/2015 01:37 AM, Martin Nowak wrote:

On 08/23/2015 07:22 AM, Rikki Cattermole wrote:

Now lets hope the next stage is smooth in the transition.


Here is a small guide on how to update a PR.
https://github.com/D-Programming-Language/dmd/pull/4922#issuecomment-133776696



# convert all commits using magicport

I haven't worked with the conversion tool before. How is this part done?

Re: D-Day for DMD is today!

[Nick Sabalausky via Digitalmars-d-announce]

On 08/23/2015 01:08 PM, Martin Nowak wrote:

On 08/23/2015 06:35 PM, Nick Sabalausky wrote:


I haven't worked with the conversion tool before. How is this part done?


It's the exact command below that line, we've incorporated that into the
makefile.



Ah, ok, I misunderstood that part.

Re: scriptlike v0.9.3

[Nick Sabalausky via Digitalmars-d-announce]

On 08/20/2015 05:44 PM, biorelated wrote:


Many thanks!
But I wish it came with a couple of examples on usage in addition to the
API.
:)



Yea, examples/tutorials for it are getting pretty high on my priority 
list for it. I want to do a blog posting or two as well.

scriptlike v0.9.3

[Nick Sabalausky via Digitalmars-d-announce]

Minor update to scriptlike: Utility library to aid in writing 
script-like programs in D.


Homepage and features:
https://github.com/Abscissa/scriptlike

On DUB:
http://code.dlang.org/packages/scriptlike

API Reference:
http://semitwist.com/scriptlike

Full Changelog:
http://semitwist.com/scriptlike/changelog.html

New in v0.9.3:
- Fixed: #16: Access to standard Phobos function hampered: 
https://github.com/Abscissa/scriptlike/issues/16

- Enhancement: Support running unittests through DUB: dub test
- Enhancement: Uses travis-ci.org for continuous integration testing.

Re: ∅MQD messaging library v1.0 released

[Nick Sabalausky via Digitalmars-d-announce]

Cool. I haven't actually used ZeroMQ yet, but it's something I've had my 
eye on.

Re: mood : simple vibe.d based blog implementation

[Nick Sabalausky via Digitalmars-d-announce]

On 08/14/2015 02:51 PM, Dicebot wrote:

A bit more details -
https://blog.dicebot.lv/posts/2015/08/In_the_mood_for_some_releasing



Nice.

One thing: can i haz rss/atom plz?

Re: SDLang-D v0.9.2

[Nick Sabalausky via Digitalmars-d-announce]

On Saturday, 1 August 2015 at 17:57:30 UTC, John Colvin wrote:


Haven't looked at this at all really, just a quick question:

Are there straightforward library calls or command line 
utilities for converting between the shared subset of json and 
SDL?


No, but there definitely should be. I'll post a ticket so I don't 
forget.

Re: SDLang-D v0.9.2

[Nick Sabalausky via Digitalmars-d-announce]

On Saturday, 1 August 2015 at 20:14:52 UTC, Nick Sabalausky wrote:

On Saturday, 1 August 2015 at 17:57:30 UTC, John Colvin wrote:


Haven't looked at this at all really, just a quick question:

Are there straightforward library calls or command line 
utilities for converting between the shared subset of json and 
SDL?


No, but there definitely should be. I'll post a ticket so I 
don't forget.


https://github.com/Abscissa/SDLang-D/issues/30

SDLang-D v0.9.2

[Nick Sabalausky via Digitalmars-d-announce]

SDLang-D: A library to parse/generate SDL (Simple Data Language) files. 
Offers both DOM and StAX/Pull APIs.


SDL is like XML/JSON/YAML, but is low-verbosity, simpler than YAML, and 
supports comments and basic datatypes. It looks like this:



// An example of SDL:
folder myFiles color=yellow protection=on {
folder my images {
file myHouse.jpg color=true date=2005/11/05
file myCar.jpg color=false date=2002/01/05
}
// Another folder
folder my documents {
document resume.pdf
}
}


SDLang-D Homepage:
https://github.com/Abscissa/SDLang-D

Changes for v0.9.2:
---
Full Changelog:
https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md

- New: Uses travis-ci.org for continuous integration testing.

- Change: Updated package.json to newer dub.json name.

- Fixed: #16: Now fixed for DUB users, too: Access Violation when using 
the pull parser.


- Fixed: #21: Remove unneeded buildOptions from DUB package config 
(fixes a DUB warning) (@schuetzm)


- Fixed: #28/#29: Wrong line count for Windows style line breaks. 
(@s-ludwig)


- Fixed: Fixed running unittests via DUB. (Part of #29) (@s-ludwig)

- Fixed: Trailing line comments incorrectly treated as line continuation 
instead of newline (Related: #20, plus libsdl-d's e565f30 and c6dc722) 
(@Dicebot)


- Improved: #22/#23: Internal improvements (@schuetzm)

Re: Beta D 2.068.0-b2

[Nick Sabalausky via Digitalmars-d-announce]

On 07/26/2015 09:55 AM, Martin Nowak wrote:

On 07/25/2015 02:20 PM, Martin Nowak wrote:

Second beta for the 2.068.0 release.

http://downloads.dlang.org/pre-releases/2.x/2.068.0/
http://ftp.digitalmars.com/


BTW, I'd like to phase out the fat 50-60MB combined zip, and add
tar.xz/gz for linux/freebsd/osx.
Does anyone still rely on the combined zip?



I think DVM still relies on it (unless I just have an old DVM on this 
machine)

Re: New D book available for pre-order: D Web Development

[Nick Sabalausky via Digitalmars-d-announce]

On 07/22/2015 11:29 AM, Kai Nacke wrote:

Hi all!

Did you notice that development of LDC has been a bit slowly in the
past? The reason is my book D Web Development, available now for
pre-order: https://www.packtpub.com/web-development/d-web-development



Congrats! This exactly the sort of book I think D could really use right 
now. D/vibe is fantastic for web, but outside of the vibe.d site there 
isn't enough written about it.

Scriptlike v0.9.2

[Nick Sabalausky via Digitalmars-d-announce]

Minor update, Scriptlike v0.9.2:

https://github.com/Abscissa/scriptlike

- Fixed: Properly flush all command echoing output (ie, in yap and yapFunc).

- Enhancement: Add a no-build configuration for projects that need to 
import/depend on Scriptlike through DUB, but use their own buildsystem.

gen-package-version v1.0.2

[Nick Sabalausky via Digitalmars-d-announce]

gen-package-version v1.0.2:
One small change:
- Now works on DMD 2.066.1 (previously required 2.067.0 or up).

In your project's dub.json:
--
dependencies: {
 gen-package-version: ~1.0.2
},
preGenerateCommands:
[dub run gen-package-version -- your.package.name --root=$PACKAGE_DIR
--src=path/to/src]
--

Re: gen-package-version v1.0.0

[Nick Sabalausky via Digitalmars-d-announce]

On 06/28/2015 01:02 AM, Nick Sabalausky wrote:

Update to gen-package-version:
https://github.com/Abscissa/gen-package-version



gen-package-version v1.0.1:
- Fixed: Don't use a broken scriptlike release (v0.9.0), use v0.9.1 instead.

In your project's dub.json:
--
dependencies: {
 gen-package-version: ~1.0.1
},
preGenerateCommands:
[dub run gen-package-version -- your.package.name --root=$PACKAGE_DIR
--src=path/to/src]
--

Re: safeArg v0.9.7

[Nick Sabalausky via Digitalmars-d-announce]

safeArg v0.9.7
https://github.com/Abscissa/safeArg/blob/master/CHANGELOG.md

- Fixed: Don't use a broken scriptlike release (v0.9.0), use v0.9.1 instead.

gen-package-version v1.0.0

[Nick Sabalausky via Digitalmars-d-announce]

Update to gen-package-version:
https://github.com/Abscissa/gen-package-version

Automatically generate a D module with version and timestamp information 
(detected from git or Mercurial/hg) every time your program or library 
is built. You can also generate a DDOC macro file (using the --ddoc=dir 
switch.) In-between builds will automatically have their own 
VCS-generated version number, including the VCS commit hash.


Now, by default, gen-package-version will NOT re-generate the output 
files if the only difference is the build timestamp. So it won't trigger 
unnecessary rebuilds of your project.


Usage is easy. Pop this in your dub.json:
--
dependencies: {
gen-package-version: ~1.0.0
},
preGenerateCommands:
[dub run gen-package-version -- your.package.name --root=$PACKAGE_DIR 
--src=path/to/src]

--

And then import:
--
import your.package.name.packageVersion;

writeln(My Cool Program , packageVersion);
writeln(Built on , packageTimestamp);
--

Full changelog:
https://github.com/Abscissa/gen-package-version/blob/master/CHANGELOG.md

New in this version:
- Change: The generated 'packageTimestamp' is changed from ISOExt format 
to human readable. The ISOExt formatted version is now called 
'packageTimestampISO'.


- Change: Value for '--module=' is no longer allowed to contain periods.

- Enhancement: Basic ability to be used as a library. See the README for 
details.


- Enhancement: Add '-r|--root' to support projects in any directory, not 
just the current directory.


- Enhancement: Minor improvements to '--verbose' and '--trace' outputs.

- Fixed: Don't update the version file (and thus trigger a project 
rebuild) if the version file doesn't need updated. Bypass this check 
with the new '--force' flag.


- Fixed: Don't rebuild gen-package-version if not needed.

- Fixed: Failure on Windows when target project is on a different drive 
letter from current working directory.

Re: safeArg v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

Another small update:

safeArg v0.9.6
https://github.com/Abscissa/safeArg/blob/master/CHANGELOG.md

One change:
- Enhancement: Add --verbose|-v to echo the generated command to stdout 
before running.

Scriptlike v0.9.0

[Nick Sabalausky via Digitalmars-d-announce]

New update to Scriptlike: A library to aid in writing script-like 
programs in D.


Home:
  https://github.com/Abscissa/scriptlike

API Reference:
  http://semitwist.com/scriptlike

Dub:
  http://code.dlang.org/packages/scriptlike

Full changelog:
  http://semitwist.com/scriptlike/changelog.html

---

In this version:
- Change: Split scriptlike.file and scriptlike.path into the following:
- scriptlike.core
- scriptlike.file.extras
- scriptlike.file.wrappers
- scriptlike.path.extras
- scriptlike.path.wrappers
Utilizes package.d to retain ability to import scriptlike.file and 
scriptlike.path.


- Change: Convert changelog from markdown to ddox so links are more 
readable.


- Enhancement: Add (opt-in) command echoing to most functions in 
scriptlike.file.


- Enhancement: Add yap and yapFunc as improved versions of 
to-be-deprecated echoCommand.


- Fixed: Make escapeShellArg const-correct.

- Fixed: Make Path.toRawString and Ext.toRawString both be pure 
@safe nothrow.

Scriptlike v0.9.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/28/2015 12:36 AM, Nick Sabalausky wrote:

New update to Scriptlike: A library to aid in writing script-like
programs in D.

Home:
   https://github.com/Abscissa/scriptlike



Scriptlike v0.9.1:
- Fixed: Fails to compile unless the makedocs script has been run.

Re: Scriptlike v0.8.0

[Nick Sabalausky via Digitalmars-d-announce]

On 06/22/2015 05:09 AM, Per =?UTF-8?B?Tm9yZGzDtnci?= 
per.nord...@gmail.com wrote:

On Monday, 22 June 2015 at 09:08:45 UTC, Per Nordlöw wrote:

Something like this

userInput(T)(string message, T x);


Correction, should be

 userInput(T)(string message, ref T x)



Good idea. Now added, and tagged v0.8.1:
https://github.com/Abscissa/scriptlike/blob/master/CHANGELOG.md

Re: gen-package-version v0.9.4: Mercurial (hg) support

[Nick Sabalausky via Digitalmars-d-announce]

On 06/14/2015 01:24 AM, Nick Sabalausky wrote:

 https://github.com/Abscissa/gen-package-version

 gen-package-version: Automatically generate a D module with version and
 timestamp information (detected from git) every time your program or
 library is built.

By request, Mercurial (hg) support now added in gen-package-version v0.9.4:

https://github.com/Abscissa/gen-package-version/blob/master/CHANGELOG.md

- Enhancement: Support detecting the version number via Mercurial (hg).
- Enhancement: Support .hgignore for Mercurial working directories.

Re: gen-package-version v0.9.3

[Nick Sabalausky via Digitalmars-d-announce]

On 06/16/2015 12:40 AM, Rikki Cattermole wrote:


Will it support hg in future?


Ask and ye shall receive ;) Now in gen-package-version's ~master:
https://github.com/Abscissa/gen-package-version/commit/a6b0aa8536c4080a5ee56f14f62aae9495a8c180

I'll add .hgignore support and then tag a new release soon, maybe tomorrow.