Re: mimeapps - finding association between MIME types and applications

[FreeSlave via Digitalmars-d-announce]

On Saturday, 16 April 2016 at 21:58:35 UTC, ag0aep6g wrote:

On 16.04.2016 20:48, FreeSlave wrote:
github repo: https://github.com/MyLittleRobo/mimeapps 
(examples included)


You've got some bad `@trusted`s in your code:


:

The constraint allows user-defined types that implicitly 
convert to const(char)[] via alias this. Such a type may, for 
example, have an unsafe opAssign, which you're mistakenly 
trusting here.


I would better use inout here, but it has problems with Tuples. I 
don't know how to rewrite this code to inout so it still remained 
buildable. The other way of course is to rewrite constraints to 
match real strings only not types with alias this.



,
:

Similarly, IniLikeReader may do unsafe stuff and can't be 
trusted.


This is usually constructed from iniLikeStringReader or 
iniLikeFileReader from inilike library, but yeah, generally it 
can be non-trusted user-defined type. Thanks for pointing out. 
Will fix it.

IDE - Coedit 2, update 3 released

[Basile Burg via Digitalmars-d-announce]

Yet another CE update.

This release improves several existing features (highlighter, 
runnable modules, library manager, gdmd support) and fixes a few 
bugs (most notably brace auto-closing).


See https://github.com/BBasile/Coedit/releases/tag/2_update_3 for 
a detailed changelog and to download.


Note that there is still no OSX version and this is unlikely to 
change in the near future.

Re: mimeapps - finding association between MIME types and applications

[ag0aep6g via Digitalmars-d-announce]

On 16.04.2016 20:48, FreeSlave wrote:

github repo: https://github.com/MyLittleRobo/mimeapps (examples included)


You've got some bad `@trusted`s in your code:


:

The constraint allows user-defined types that implicitly convert to 
const(char)[] via alias this. Such a type may, for example, have an 
unsafe opAssign, which you're mistakenly trusting here.



,
:

Similarly, IniLikeReader may do unsafe stuff and can't be trusted.



Related libraries:

https://github.com/MyLittleRobo/desktopfile - reading and executing
.desktop files.
https://github.com/MyLittleRobo/mime - parsing shared MIME type database
and detecting MIME types of files.


These have bad `@trusted`s, too. I'm not going to go over all of them, 
but here are some examples:



,
,
:

Trusting template arguments again.


:

Reversing the bytes of arbitrary data, including pointers, is not 
memory-safe.

Re: mimeapps - finding association between MIME types and applications

[Eugene Wissner via Digitalmars-d-announce]

On Saturday, 16 April 2016 at 18:48:36 UTC, FreeSlave wrote:
mimeapps is a library for detection of which applications can 
be used to open files of given MIME type.


Note: this is essential only for systems that follow 
Freedesktop specifications, i.e. Linux, BSD and some others. MS 
Windows and OS X have their own file type associations systems.


github repo: https://github.com/MyLittleRobo/mimeapps (examples 
included)

dub package: http://code.dlang.org/packages/mimeapps
Specification: 
https://www.freedesktop.org/wiki/Specifications/mime-apps-spec/


Use cases:

1. Building "Open with" menu.
2. Finding user preferred application for specific file type, 
e.g. text editor for text/plain or file manager for 
inode/directory.
3. Finding user preferred application to open uri, e.g. user 
preferred web browser for http and https links.


Related libraries:

https://github.com/MyLittleRobo/desktopfile - reading and 
executing .desktop files.
https://github.com/MyLittleRobo/mime - parsing shared MIME type 
database and detecting MIME types of files.



Wow. I just wanted to port libmagic since need it. Can you write 
a short introduction how I can work with the magic database 
(defining mime type of a file based on its content)?

mimeapps - finding association between MIME types and applications

[FreeSlave via Digitalmars-d-announce]

mimeapps is a library for detection of which applications can be 
used to open files of given MIME type.


Note: this is essential only for systems that follow Freedesktop 
specifications, i.e. Linux, BSD and some others. MS Windows and 
OS X have their own file type associations systems.


github repo: https://github.com/MyLittleRobo/mimeapps (examples 
included)

dub package: http://code.dlang.org/packages/mimeapps
Specification: 
https://www.freedesktop.org/wiki/Specifications/mime-apps-spec/


Use cases:

1. Building "Open with" menu.
2. Finding user preferred application for specific file type, 
e.g. text editor for text/plain or file manager for 
inode/directory.
3. Finding user preferred application to open uri, e.g. user 
preferred web browser for http and https links.


Related libraries:

https://github.com/MyLittleRobo/desktopfile - reading and 
executing .desktop files.
https://github.com/MyLittleRobo/mime - parsing shared MIME type 
database and detecting MIME types of files.

Re: Official dub packages for Debian and Ubuntu

[Russel Winder via Digitalmars-d-announce]

On Fri, 2016-04-15 at 20:03 +0200, Jordi Sayol via Digitalmars-d-
announce wrote:
> […]
> Many thanks Andrei, and all d-apt users.

Thanks for creating and running D-Apt – all it's users a A-D-Apt-able.
;-)


I wish there was an equivalent RPM store for Fedora Rawhide. I'd be
happy to help out creating something, but not if I am the only user.

-- 
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



signature.asc
Description: This is a digitally signed message part

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Friday, 15 April 2016 at 09:15:05 UTC, Johannes Pfau wrote:

Am Thu, 14 Apr 2016 23:16:49 +
schrieb Matthias Klumpp :

On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau 
wrote:
> OSS projects do not use interface files though: It prevents 
> inlining of functions and there's no real benefit for OSS 
> projects. Interface files are (theoretically) useful for 
> closed source libraries if you don't want to ship the source 
> code.


I think those would also be useful for FLOSS projects, if you 
ship a compiled binary and don't want to recompile the code. 
This is the case for example for very huge projects which take 
long to compile (think in WebKit or Eigen3 dimensions), or for 
Linux distributions which want to separate as much code as 
possible and prevent code duplication and statically linked 
stuff to make security uploads easier and faster.


I totally agree it makes sense to ship precompiled libraries. 
But even with precompiled libraries you can still ship the full 
source code instead of header files. An example:


[...]

The important point here is that you can use the normal source 
code as headers. The source code of a library is not 
recompiled, it's only used to parse function definitions and 
similar stuff. The compilation speed should be very similar for 
.d and .di files as well. The benefit of shipping the complete 
source code is that fooFunc can be inlined into main.d with the 
foo.d source, but not with foo.di.


Shipping .di files only makes sense if you have to hide the 
source code.


Or when the source-code is very large, I guess. But the way D 
handles this makes much sense to me!



[...]


I agree having a common ABI should be prioritized. It's really
annoying for distributions (E.g. archlinux installs 
druntime/phobos into

different directories /usr/include/dlang/{gdc,dmd,ldc} and never
installs compiled libraries). Shared D libraries are useless in
practice because of this issue.


Yeah, and this makes D pretty hard to sell to distributors. While 
I would argue that for applications it is no longer essential to 
be packages and shipped by distributions (or rather it won't be 
in future), for a "new" programming language this is a crucial 
thing.
As soon as it is easy to try out for developers, more people will 
"just try it" and maybe stick with it. If testing it is hard due 
to incompatible standard libraries, runtimes, or simply missing 
free D compilers, people won't try it.
In fact, that it also is pretty hard for people to compile 
applications written in D on distributions other than Debian (and 
even there it was not without issues...) was *the* biggest 
concern for me.


This needs coordinated work from all compiler teams though. For 
GDC I'll finally have to finish shared library support first...


That would be awesome to have! Thank you for working on this!

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Saturday, 16 April 2016 at 09:48:01 UTC, Joseph Rushton 
Wakeling wrote:

[..]
As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without 
downloading stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full 
sourcecode present somewhere?


Is there anything wrong -- in principle -- with (for now) 
treating open-source D libraries much like the various Boost 
C++ libraries, which AFAICT are almost entirely header-based?


It's a bit ugly, because we are essentially embedding code copies 
into every binary, instead of having a proper shared library 
stuff can link to (and we also need to recompile everything 
again).
Aside from that, there is no real issue - Debian policy allows 
doing that, and in fact, this is the thing I am currently 
attempting to do to work around the ABI issues.


I ask because so far as I can tell that would work around the 
immediate problems of compiler incompatibilities, it would not 
add any extra work compiler-wise that's not already there with 
dub's current way of doing things, and for template-heavy D 
code (which is quite a lot of code), it makes no difference, 
since that would have to be available in .d or .di files anyway.


Jup - what dub would still need to do though is to find the 
globally installed software, so we don't need to patch each 
dub.(json|sdl) file to find the code which was installed via 
distro packages.
At time, I install the D code into `/usr/include/d/`[1] 
where dub could theoretically automatically find it.


[1]: Probably not the best location since this isn't actually a 
header... (alternative could be `/usr/share/dlang/`)

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 16:29:31 UTC, Matthias Klumpp wrote:
FTR, I filed 
https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
we are lucky, this still has a chance to go in.


That's great, thank you very much.

As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without 
downloading stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full 
sourcecode present somewhere?


Is there anything wrong -- in principle -- with (for now) 
treating open-source D libraries much like the various Boost C++ 
libraries, which AFAICT are almost entirely header-based?


I ask because so far as I can tell that would work around the 
immediate problems of compiler incompatibilities, it would not 
add any extra work compiler-wise that's not already there with 
dub's current way of doing things, and for template-heavy D code 
(which is quite a lot of code), it makes no difference, since 
that would have to be available in .d or .di files anyway.