February 25
On Tuesday, 25 February 2020 at 03:28:07 UTC, Akira1364 wrote:
> On Friday, 15 November 2019 at 09:02:55 UTC, Basile B. wrote:
>> [...]
>
> I clearly didn't *intentionally* leave out the history. It simply didn't exist in the tarball someone on Reddit found, that I restored the repo from. Looking at some other comments from more recently here though it seems they did later on find one with the history intact (and more up to date sources), so I'll see if I can merge that all in.

Don't bother. You will not be able to develop it anyway. While you seemed to mostly care about the dependencies I've already pushed new features and fixes like

- the global compiler ;
- during debug, inspect variable from mouse motion on the editor ;
- fixed constant load even on idle (was 3-4% on my 5-6 years old hardware)
- support for GNU-style messages ;
- removed some confusing fields in the compiler path editor ;

Most of these stuff can only be programmed by someone who practices D a bit at least.

You (non-nominative) have to follow the language devel constantly and adapt the IDE accordingly (support for GNU messages is there because I check the DMD PRs and the issues daily). In the same order of ideas I'm pretty sure that you don't even know that at some point SemVer version 2 will have to be supported. There's also some activity related to the tools and DMD as a library... You see you have to follow what's happening.

Also since there are (almost) not tests you risk to break things without even realizing. You need to have advanced projects, advanced scripts (for example I have a few that link automagically dbeaengine or cairo, they allow me to verify that the runnables and the module registry work).

But if you want to give a hand there are a few areas of the software that don't really require to know D well. The terminal for example... I'm sure that a Lazarus developer would be useful since it's mostly about a GTK2 widget. I still don't manage to put those damn scrollbars... Another thing is the support for GTK3. Dexed just crashes at startup when use the GTK3 widget set. The profile viewer is also something that can be enhanced, though if I really need to profile I would rather use callgrind + KCacheGrind.
February 25
On Tuesday, 25 February 2020 at 14:48:28 UTC, Basile B. wrote:
> Most of these stuff can only be programmed by someone who practices D a bit at least.

I don't really agree, to be honest with you. I'd say at the very least 80% of it doesn't actually require a lot of D knowledge at all as it's just pretty universal IDE stuff (process management, etc.)

I did quite a bit more than just rework the dependencies, also, and none of it was very difficult at all. For example, I reworked literally all the uses of container classes in the entire project around LGenerics:

https://github.com/avk959/LGenerics

which is significantly more performant than any of FPC's built-in non-generic *or* generic ones. I also fixed several general bugs, like by getting rid of your unnecessary custom JSON encoding translator (which didn't even completely work properly) and just using normal stream functionality instead.

Also, a lot of the issues you seem to have with the LCL / FPC and such just don't exist in the trunk versions, which is why I opted to use them to work on it instead of the "stable" ones.


February 25
On Tuesday, 25 February 2020 at 19:53:58 UTC, Akira1364 wrote:
> [...]

Also, I actually have been taking a bit of time to familiarize myself with D a bit more specifically because I felt like I probably should if I was going to keep working on Dexed.

I ported my FPC implementation of the "Binary Trees" benchmark (which is currently in first place on the benchmarksgame website) to D, and even managed to get it just about as fast (on my machine at least):

https://github.com/Akira13641/BinaryTreesBenchmark


February 25
On Tuesday, 25 February 2020 at 19:53:58 UTC, Akira1364 wrote:
> [...]
> I also fixed several general bugs, like by getting rid of your unnecessary custom JSON encoding translator (which didn't even completely work properly) and just using normal stream functionality instead.
>
> Also, a lot of the issues you seem to have with the LCL / FPC and such just don't exist in the trunk versions, which is why I opted to use them to work on it instead of the "stable" ones.

Yeah but did you try to load a goddamn JSON recipe that **has** the BOM written ?
This stuff was there for a good reason you know ;)
February 26
On Tuesday, 25 February 2020 at 21:45:04 UTC, Basile B. wrote:
> Yeah but did you try to load a goddamn JSON recipe that **has** the BOM written ?
> This stuff was there for a good reason you know ;)

The reason BOMs weren't working for you was because you were using a TMemoryStream to actually load the JSON files, and TMemoryStream is just a stream of raw bytes that knows absolutely nothing about encodings.

All I had to do to get rid of your 30 lines of "BOM skipping" code was change the file loading part to this:

```
List := TStringList.Create;
List.LoadFromFile(FFileName, TEncoding.UTF8);
Stream := TStringStream.Create(List.Text, TEncoding.UTF8, False);
List.Free;
Stream.Position := 0;
```

And then continue by creating the TJSONParser from `Stream`. Doing it that way works correctly BOM or no BOM.

February 27
On Wednesday, 26 February 2020 at 03:10:30 UTC, Akira1364 wrote:
> On Tuesday, 25 February 2020 at 21:45:04 UTC, Basile B. wrote:
>> Yeah but did you try to load a goddamn JSON recipe that **has** the BOM written ?
>> This stuff was there for a good reason you know ;)
>
> The reason BOMs weren't working for you was because you were using a TMemoryStream to actually load the JSON files, and TMemoryStream is just a stream of raw bytes that knows absolutely nothing about encodings.
>
> All I had to do to get rid of your 30 lines of "BOM skipping" code was change the file loading part to this:
>
> ```
> List := TStringList.Create;
> List.LoadFromFile(FFileName, TEncoding.UTF8);
> Stream := TStringStream.Create(List.Text, TEncoding.UTF8, False);
> List.Free;
> Stream.Position := 0;
> ```
>
> And then continue by creating the TJSONParser from `Stream`. Doing it that way works correctly BOM or no BOM.

Okay, I recognize that I've been a bit unfair in the previous message but remember that this constructor overload does not exist yet in the freepascal library version 3.0.4, so I could not use it, hence those 30 lines had to be written.
February 27
On Wednesday, 26 February 2020 at 03:10:30 UTC, Akira1364 wrote:
> On Tuesday, 25 February 2020 at 21:45:04 UTC, Basile B. wrote:
>> Yeah but did you try to load a goddamn JSON recipe that **has** the BOM written ?
>> This stuff was there for a good reason you know ;)
>
> The reason BOMs weren't working for you was because you were using a TMemoryStream to actually load the JSON files, and TMemoryStream is just a stream of raw bytes that knows absolutely nothing about encodings.
>
> All I had to do to get rid of your 30 lines of "BOM skipping" code was change the file loading part to this:
>
> ```
> List := TStringList.Create;
> List.LoadFromFile(FFileName, TEncoding.UTF8);
> Stream := TStringStream.Create(List.Text, TEncoding.UTF8, False);
> List.Free;
> Stream.Position := 0;
> ```
>
> And then continue by creating the TJSONParser from `Stream`. Doing it that way works correctly BOM or no BOM.

Okay, I recognize that I've been a bit unfair in the previous message but remember that this constructor overload does not exist yet in the freepascal library version 3.0.4, so I could not use it, hence those 30 lines had to be written.
Next ›   Last »
1 2 3