Re: Sublime Text Syntax Definition Rewrite
On Friday, 1 March 2019 at 03:44:09 UTC, Benjamin Schaaf wrote: On Thursday, 28 February 2019 at 11:33:13 UTC, Andrea Fontana wrote: When the next stable will be released? Hopefully soon™, we don't want to commit to any deadline though. Good news: Sublime Text 3.2 has just been released, including all the aforementioned improvements for D. The full list of changes can be seen here: https://www.sublimetext.com/blog/articles/sublime-text-3-point-2
Re: Sublime Text Syntax Definition Rewrite
On Thursday, 28 February 2019 at 11:15:05 UTC, Dmitry wrote: If I open 3-10 GB file (log) and then try to find something, it's almost unusable. For example, I pressed Ctrl+F and entered first char. After it, Sublime may become frozen for (just for example, it depends) 40 seconds. Then second char — same. Etc. So, just to open file and find first required record (like '2019-02-28, 08:05:') may take 5 minutes (and again, it depends). As I understand, it's because Sublime tries to find and highlight all same sequences. Any old editor (without such highlighting) works faster. In terms of search performance this comes from "Highlight matches" being enabled. Turning off that option yields a massive performance increase as we're no longer searching the whole file for every key-press. P.P.S. Also there are some problems when opened many tabs (6-7 windows, 100+ tabs). Then I can't drag the window to second display. It changes size to minimal possible and I can't catch it (there are only sublime icon + window's icons) This sounds like a bug, a bug report on https://github.com/SublimeTextIssues/Core/issues would be much appreciated :)
Re: Sublime Text Syntax Definition Rewrite
On Thursday, 28 February 2019 at 10:11:23 UTC, Andre Pany wrote: On Thursday, 28 February 2019 at 00:30:24 UTC, Benjamin Schaaf wrote: Hello all, I've recently gotten a massive rewrite of the D syntax highlighting merged into the Sublime Text default packages. This has since been deployed in the most recent development version 3192 (license required) and will be shipping with the next stable. [...] Great work! There is also the "D Language Server" available (https://github.com/d-language-server/dls) which can be used to add code completion, linting and formatting. You may check whether you can make direct use of DLS in your plugin without usage of the generic LSP plugin (https://github.com/tomv564/LSP). Kind regards André We currently don't have any plans for language server support in the default packages. This kind of stuff we usually either put into the core text editor or leave to 3rd party plugin authors.
Re: Sublime Text Syntax Definition Rewrite
On Thursday, 28 February 2019 at 05:37:42 UTC, Dmitry wrote: On Thursday, 28 February 2019 at 00:30:24 UTC, Benjamin Schaaf wrote: I've recently gotten a massive rewrite of the D syntax ... Hope you enjoy! --- Thank you! Looking forward to try it (right now it shows 'no update available', build 3176) 3176 was the latest stable build, you'd need to change to the development versions (requires a license) to get more recent updates or you can install the Packages manually. Is this the reason why it works extremely slow with big files? :D I know you're just taking a fun jab but from personal experience its behaved pretty well with multi-GB files. All the corner cases we're aware of where it does become slow are algorithmic problems where a change in language really wouldn't help :)
Sublime Text Syntax Definition Rewrite
Hello all, I've recently gotten a massive rewrite of the D syntax highlighting merged into the Sublime Text default packages. This has since been deployed in the most recent development version 3192 (license required) and will be shipping with the next stable. Anyone trying Sublime Text has probably noticed the poor D support. Here's a very incomplete list of everything that's been fixed/improved: * Functions, classes, interfaces, enums, structs, unions, templates and aliases are now properly indexed, making GoTo Definition work properly * Function/Template calls are properly marked, making GoTo Reference work properly * Nested comments now work as expected * Shebangs are properly highlighted * Ligatures are now properly supported * `..` no longer highlights as a floating point * Strings are now properly highlighted, including postfixes and delimited strings * Token strings actually highlight tokens now * Attributes, including UDAs, are highlighted properly * Automatic indentation is no longer broken (Typing `} catch...` would re-indent the line) * Arguments are highlighted as actual arguments * Contracts are properly highlighted now You can find the pr here: https://github.com/sublimehq/Packages/pull/1850 If you do find a bug with the syntax highlighting or just something that could be done better please leave a bug report on the repository, I'll be maintaining it for the foreseeable future: https://github.com/sublimehq/Packages/issues If you don't have a license you can still use the new syntax highlighting before the next stable build by cloning the repository and symlinking the `D` folder into your Sublime Text "Packages" directory (Details in the README). You can download Sublime Text here: https://www.sublimetext.com/3 Hope you enjoy! --- Full disclosure: I work for Sublime HQ. Though I'd love to, we don't use D internally for anything.
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 23:37:59 UTC, Leandro Lucarella wrote: On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: Alongside I've also written (an admittedly hacky) sphinx (http://www.sphinx-doc.org/en/stable/) extension that provides a domain and autodocumenter for D, using libdparse and pyd. Where can I get the Sphinx extension? :-D https://github.com/BenjaminSchaaf/sphinxddoc It has a sphinx language domain for D and an autodocumenter. I've written a python extension using pyd and libdparse to parse D source into a consumable json format. I then use that output to autodocument the code. Its a bit of a hack, but I find having proper control of the output and being able to use sphinx themes is worth it compared to the alternative.
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote:
On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf
wrote:
daffodil is a image processing library inspired by python's
Pillow (https://pillow.readthedocs.org/). It is an attempt at
designing a clean, extensible and transparent API.
https://github.com/BenjaminSchaaf/daffodil
https://benjaminschaaf.github.io/daffodil/
The library makes full use out of D's templates and
metaprogramming. The internal storage mechanism is entirely
configurable from almost every endpoint. File headers are
directly loaded into structs defining them, removing most of
the difficulties in reading them according to spec. The image
type and loading API is entirely extensible, making extra
image formats entirely self-contained.
Currently only loading and saving of simple BMP images is
supported, with convolution and Gaussian Blur filters and flip
transformations. Its still early in development, but I'd love
to get some feedback on it.
Example:
---
import daffodil;
import daffodil.filter;
import daffodil.transform;
void main() {
auto image = load!32("daffodil.bmp");
image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");
image.flipped!"y".save("upside_down_daffodil.bmp");
}
---
The license is MIT, so feel free to do whatever you want with
the code. Issues and pull requests are of course welcome ;)
Alongside I've also written (an admittedly hacky) sphinx
(http://www.sphinx-doc.org/en/stable/) extension that provides
a domain and autodocumenter for D, using libdparse and pyd.
Hi there. Took a quick look at the source and it seems really
nice! I like your idea of extensibility for color conversion.
Also, image I/O seems to be set up quite nicely for a starting
point. Although I have to comment that bit depth shouldn't be a
template argument, in my opinion. When loading images, bit
depth should be determined in the runtime, depending on the
image you'd be loading at the moment. Or am I wrong? - do you
have some other way of handing this case?
Also wanted to let you know I've been working on a similar
library for some time now [1].
Hope we could merge some modules and learn from each other, and
not have multiple different implementations of the same stuff.
Please let me know if your interested.
[1] https://github.com/ljubobratovicrelja/dcv
The problem with not knowing bit depth at compile time, is that
you're now forced to store the image internally as plain bytes.
So if you wanted to add two colors, you end up with ubyte[4] +
ubyte[4] instead of int + int. At some point you're going to have
to use a proper numerical representation (ie. long), or be faced
with slow calculations (ie. bigint).
Other libraries (eg. ImageMagick) get around this by just using
longs as the internal representation. Daffodil allows you to
control this. So if you know you will never use more than 4 bytes
per color, you don't have to pay for anything more. If you don't
know, you can just use 8 and essentially have the same behaviour
as ImageMagick.
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
On 01/07/2016 9:35 AM, Benjamin Schaaf wrote:
daffodil is a image processing library inspired by python's
Pillow
(https://pillow.readthedocs.org/). It is an attempt at
designing a
clean, extensible and transparent API.
https://github.com/BenjaminSchaaf/daffodil
https://benjaminschaaf.github.io/daffodil/
The library makes full use out of D's templates and
metaprogramming. The
internal storage mechanism is entirely configurable from
almost every
endpoint. File headers are directly loaded into structs
defining them,
removing most of the difficulties in reading them according to
spec. The
image type and loading API is entirely extensible, making
extra image
formats entirely self-contained.
Currently only loading and saving of simple BMP images is
supported,
with convolution and Gaussian Blur filters and flip
transformations. Its
still early in development, but I'd love to get some feedback
on it.
Example:
---
import daffodil;
import daffodil.filter;
import daffodil.transform;
void main() {
auto image = load!32("daffodil.bmp");
image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");
image.flipped!"y".save("upside_down_daffodil.bmp");
}
---
The license is MIT, so feel free to do whatever you want with
the code.
Issues and pull requests are of course welcome ;)
Alongside I've also written (an admittedly hacky) sphinx
(http://www.sphinx-doc.org/en/stable/) extension that provides
a domain
and autodocumenter for D, using libdparse and pyd.
Doesn't use allocators or Manu's color work, yup yup not
interested.
In terms of std.experimental.color, one of the things I focused
on was extensibility. What if someone came along and had their
own color space they needed to implement? With
std.experimental.color, the only option you currently have is
editing the library. If it gets included into phobos, then
suddenly your "I want to implement my own color space" has turned
into editing the standard library.
Albeit currently rough around the edges, all you have to do to
implement your own color space in daffodil, is to implement the
ColorSpace interface.
I haven't looked into using allocators yet, but I've put it on
the horizon.
daffodil, a D image processing library
daffodil is a image processing library inspired by python's
Pillow (https://pillow.readthedocs.org/). It is an attempt at
designing a clean, extensible and transparent API.
https://github.com/BenjaminSchaaf/daffodil
https://benjaminschaaf.github.io/daffodil/
The library makes full use out of D's templates and
metaprogramming. The internal storage mechanism is entirely
configurable from almost every endpoint. File headers are
directly loaded into structs defining them, removing most of the
difficulties in reading them according to spec. The image type
and loading API is entirely extensible, making extra image
formats entirely self-contained.
Currently only loading and saving of simple BMP images is
supported, with convolution and Gaussian Blur filters and flip
transformations. Its still early in development, but I'd love to
get some feedback on it.
Example:
---
import daffodil;
import daffodil.filter;
import daffodil.transform;
void main() {
auto image = load!32("daffodil.bmp");
image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");
image.flipped!"y".save("upside_down_daffodil.bmp");
}
---
The license is MIT, so feel free to do whatever you want with the
code. Issues and pull requests are of course welcome ;)
Alongside I've also written (an admittedly hacky) sphinx
(http://www.sphinx-doc.org/en/stable/) extension that provides a
domain and autodocumenter for D, using libdparse and pyd.
