dockimbel · HackerTrans

dockimbel

no profile record

Submissions

New Nano-Tech to Control the Brain Using Magnetic Fields

46 pointsby dockimbel2 anni fa6 comments

comments

8 anni fadiscuss

> And, in the end, it still doesn't help the long line where you have no idea what is a function call, and what is just an argument.

And still people have no issue reading and writing code in Rebol and Red. And still 10 non-core team programmers provided a quarter of the bugfixes in last 6 months... It's either magic, or it's you trying desperately to paint a bad picture of Red, without any interest at all in understanding it.

> > That gives a 4.83% result...so about 5000 times more than your claim > Wow. You've really, really "put my extravagant claims to the test". Well, you've actually just reinforced my words. A tiny fraction of all bugfixes ever get tests.

And yet, more dishonesty again... You've picked up the intermediary value in my demonstration above, and not the final one: 27.3%. So 27% is a "tiny fraction"? Makes sense. You are that desperate now to resort to cheap tricks like that?

> Yup. The person accusing me of being arrogant and condescending goes to great lengths to find out who I am and revert to ad hominem attacks.

Googling your HN id is certainly not "going to great lengths", and I was curious about your background. From your first post in this HN thread, you have clearly shown aggressivity, misrepresentation, wilful ignorance and dishonesty towards Red project, as I have proved several times, like this "0.001%" of bugfixes having tests, while the reality is 27.3%. Where's your apology for posting fake information on HN clearly meant to mislead readers?

> A real class act you are.

That is left for the crowd to judge, as is your performance in this whole thread. You have missed a good opportunity to actually have an interesting discussion about a new language that is attempting to go in a different direction. And surely, we are far from perfect, but that does not warrant such misplaced anger from the start towards us and our work.

Case closed for me.

8 anni fadiscuss

> 1. Malignant output from react/link, https://github.com/red/red/issues/3713 > One-line fix, sure. Where's the test?

You haven't really looked at the fix, nor do you understand what the issue is about...yet you think you are warranted to emit a quality judgement about it.

The issue is about `react/link` function generating a too long output when it encounters an error. That output includes references to potentially heavy graphic objects spreading over dozens or hundreds of lines, while the user only needs the beginning of that output (one or two lines), in order to identify which reaction code is concerned by that error.

The fix restricts printing everything using `probe code` to printing only the first 80 characters `print mold/part/flat code 80` (adding a flattening too using `/flat` refinement to remove eventual line breaks in that output).

This is typically a case where no test is needed nor desired, because:

* it is just about shortening a part of the output in an error report to a decent size instead of letting it go unchecked. It has no possible side-effect on anything else in the codebase.

* the replaced code cannot fail in any way, as `mold/part/flat` will deliver a properly cropped and sanitized string regardless of what `code` refers too. And that is guaranteed by the unit tests on `mold` in the tests suite. [1]

If someone would submit a test for such fix as a PR, it would be rejected at once, as it would be a waste of time/bandwidth/storage/resources. Its author would be viewed as very naive, or extremely dogmatic, as you are here in your posts.

> 2. new-line flags are not cleared on subsequent calls, https://github.com/red/red/issues/3707 > Severl line-fix. Where's the test?

On the principle, that one should have a regression test added, I agree. But I did not add one because:

* this function is just for visually formatting blocks by adding a new-line marker at desired place(s). This is rarely used function, and with the `/skip` refinement, it is an extremely rare occurence in user code. In the Red codebase, out of 157 occurrences, `/skip` is present only 5 times, and only in Rebol parts, not Red parts, so unaffected by this fix.

* this function has no impact on the rest of a user app code, as it is used only for pretty-printing some outputs in the console. New-line markers could, in theory, be misused to be the base of some funky algorithms, but I have never heard of anyone ever doing that in Rebol or Red world.

* this simple case can be left for a contributor to softly start learning about Red language and our testing framework, while doing a useful contribution. Each missing `test.written` tag in a fixed ticket is a good opportunity for contribution.

Therefore, the regression risk associated with not writting any test for this feature is extremely low. So, in such case, I am willing to trade the time to write the tests for that, for making another fix, or advancing on another feature. In a future batch-processing of those missing tests (as explained in detail in another post), or once we reach the "catch-up" stage in 0.9, if nobody did contribute it, we will write the tests for this one, in order to reach full coverage. I don't expect a dogmatic programmer to understand this kind of trade-off, anyway.

> 3. stack overflow on limited append/insert, https://github.com/red/red/issues/3705 > The fix contains a single test even though the issue provided three different failure modes

Correct. Though, `append` is a shortcut for `head insert tail`, so the `append` features are implemented inside `insert` native function. The provided test seems to only cover `insert/dup` case:

     --assert 5000 = length? head insert/dup #{} #{20} 5000

but actually, it covers both, because the implicit `tail` in `append` has no effect on an empty series like here (the `#{}` binary series). So `head insert/dup #{}` or `append/dup #{}` are both going through the same code paths internally. The only diverging path is on the last 2 changed lines of the fix. Though, other existing tests in the test suite are already covering that [2], so no worries.

For the third case, it's indeed missing, and the probable explanation is that the developer missed it, as it only appears in a later comment in the ticket, and not in the main description on top of the ticket.

> I remember seeing a "status.tested" which added easily a hundred lines of new code with zero tests.

The only parts I can think of where hundreds of lines of new code would not be covered by at least some tests are in the View module (our GUI library). Those kind of tests are usually very costly to write, complicated to test properly (because of different rendering on different OS), and hard to automate on our headless CI servers. Though, even there, we try to do something about it, by providing a prototype "null" backend [3] for testing at least the platform-independent parts of the View engine, and we got also recently a contribution for testing some image-related features on Windows platform. [4]

[1] https://github.com/red/red/tree/master/tests/source/units

[2] https://github.com/red/red/blob/master/tests/source/units/se...

[3] https://github.com/red/red/tree/master/modules/view/backends...

[4] https://github.com/red/red/tree/master/tests/source/view

8 anni fadiscuss

> Almost all issues are fixed by the same two people who develop Red.

Let's look at the reality by taking all the fix commits (prefixed with "FIX:") on red/red repo in the last 6 months and grouping them by author:

    qtxie        : 97
    dockimbel    : 39
    bitbegin     : 21
    endo64       : 6
    Rudolf       : 6
    Toomas       : 4
    greggirwin   : 3
    semseddin    : 3
    FLuX LoOP    : 2
    Vladimir     : 2
    x8x          : 2
    PeterWAWood  : 1

qtxie and dockimbel are the two main contributors to the repo, they weight a total of 139 commits, while the others together total 50 commits. This gives the following ratios:

    main ones : 73%
    others    : 27%

So more than a quarter of the last 6 months fixes are made by other than the two main contributors. So much for the exaggerated claim...

> Perhaps it's due to the fact that about zero percent of Red code is documented?

So comments don't count as documentation now? See my other replies for the comment stats.

> Or that "Code written by experienced users (and Red codebase in particular) is a hard nut to crack"?

10 different non-main contributors provided 27% of all the fixes in the last six months. They must be incredibly smart or, maybe mind readers in order to achieve that, right?

Let me propose another explanation: maybe the source code is not that difficult to understand, as you desperately try to misrepresent it in this whole thread? Maybe, with the help of the rest of the community, contributors can figure it out, even with low amount of documentation?

Maybe your all rambling here is just is because you wanted to contribute, but expected a "first-class" treatement, didn't find a full documentation offered to you on a golden plate, so went on a bashing/trolling session here on HN, in a pathetic attempt to discredit our work? That sounds as a likely explanation of your passive-aggressive tone, dishonesty and wilful ignorance in your posts here.

> It's a one-line fix. So, surely, it could be fixed by someone else but the author of the language?

Lol...that's hilarious. So the author of the language is forbidden from making fixes to his own creation, like a oneline-fix if he wants to? No kidding! The way that specific ticket was reported could have let think that the root cause could have been a deep issue in the reactive framework. So, while screening the tickets, as the author and maintainer of the reactive framework code, I identified this ticket as for me to explore, then ran the code to reproduce the problem annoying the reporter, and immediatly identified an harmless excessively verbose output on reactions processing errors. At this point, stepping into the code to make a one-line fix was the right thing to do, as I already spent time on investigating it.

> 336 lines of no significant comments other than trivia for the author himself.

How dishonest again... What you call "trivia for the author himself" are actually very important comments, as they are good clues for some more complex parts of the code. So now, even when you find comments in the code, you dismiss them as "not significant" and "for the author himself"... Moreover, you don't mention the 20 docstrings that document the public functions interface in that file, nor the full reference documentation [1], that cover all the features implemented in that file...

> "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments

"no comments"? I count 125 lines of comments there...more dishonesty. This file is the recipient for the low-level part of about 100 "native" functions (`native!` datatype at user level). All those functions are independent from each other. Their size ranges from 2 to 90 lines, with a significant number of small trampoline functions, and the code there is very explicit. Each native's interface is fully described with docstrings in [2]. If there is some significant extra commenting efforts to do in the codebase, it's really not in this file.

> And since very very few of those lines are covered by any tests (even for issues reported and fixed)

Proven wrong in details in other replies.

> how is anyone except the two authors can ever fix those issues or contribute?

Demonstrated at the beginning of this post.

> If "Code written by experienced users (and Red codebase in particular) is a hard nut to crack", how can you expect people to believe in it's "simplicity and fun"?

That's a non-sequitur. A complex system can have a simple user interface. In our case, most of the codebase in written in Red/System, for system programming purpose. System programming is far from simple or fun for most people, yet that has no bearing on Red, which lives at a higher abstraction level, and that users are enjoying for its "simplicity and fun". Can Python be simple to use, even if it's implemented in complex C code?

[1] https://doc.red-lang.org/en/reactivity.html

[2] https://github.com/red/red/blob/master/environment/natives.r...

8 anni fadiscuss

Here are a some facts about Red to debunk your attempt at spreading false information, like the "no tests" and "no comments". For the record, we have written a large number of unit tests (in addition to the regression tests mentioned above) since the beginning:

* 22196 tests for Red (with ~10k of them running once for the compiler, once for the interpreter)

* 9847 tests for Red/System

Without this large test suite, the development of Red would simply be impossible. Though, the features coverage is still not exhaustive, as we are still lacking tools for measuring it (contributions welcome!).

Now for the supposedly total absence of comments, here are some stats from red/red repo extracted using a simple Red script [1]:

    -- Type -- FileCount -- LOC -- Comments -- Cmts/LOC (rounded to nearest integer)

       .r         39       25186      3507        14%
       .red       48       16495       776         5%
       .reds     154       85742      7687         9%

Basically, .r represents our toolchain code in Rebol, while all the runtime and standard library are in .red and .reds (Red and Red/System respectively).

Those ratios are not bad, but could be better (10-15% in each category would be a good goal). More comments could be still added in some complex code sections, though embedding a full documentation of the code, in the code, is not our approach (see more explanations below). As an extra note, I have noticed a pattern with wannabee contributors with no system programming skills, of thinking that heavy commenting in the runtime low-level code would magically make them become system programmers...

The plan has always been to provide architecture-oriented documents and code maps to ease the navigation for core contributors. Though, the core team does not have the resources for now to do that, as our short/mid-term roadmap is already overloaded. Some of our contributors have documented some parts, but those docs are scattered around, and in multiple languages, not necessarily in English.

I am also taking this opportunity to address those points from a higher perspective. Given:

* the unusually large spectrum of the project for a programming language (stack of multiple languages, very rich standard library, cross-platform, self-contained,...),

* the bootstrapping process that would lead us to the aimed selfhosted Red in 2.0,

* the funding needs to sustain the project both in short/mid/long-terms,

* our business goals (in addition to the purely technical ones),

* expectations of low number of contributors until 1.0 (due to some unique aspects of our stack),

we have strived to find ways to go as fast as possible through the bootstrapping phase. So since the beginning, we have taken shortcuts, to implement the features needed for 1.0 as quickly as possible. That means less comments in the code (as the team is small and work at the same location), postponing the writing of many regression tests, postponing some design decisions and some edge cases processing, writing only minimal survival docs for the team and close contributors.

So, FYI, there is a "catch-up" stage planned between 0.9 and 1.0, where we will address those gaps, as we want a rock-solid and properly documented, 1.0. Moreover, when all design decisions are not set in stone, systematically testing/documenting all the features or code parts that may be dropped later is not winning move. In practice, regressions are rare in Red codebase, so the missing regression tests are not a show-stopper either, and we can live with that until 0.9.

[1] https://gist.github.com/dockimbel/2af078e02e56fcc092aea771de...

8 anni fadiscuss

Not liking Red is understandable. Programming languages, as largely subjective HCI, cannot appeal to every single software developer. Though, that is not a reason to be dishonest, and trying to paint a bad picture of our work (even in fallacious ways, as demonstrated below).

> One of the reasons is that the Red community is very small and entrenched.

"Entrenched" is just your opinion, not a fact. Given the rest of your post(s), your opinions about the Red project are demonstrably uninformed and highly subjective.

> They know everything that comes out of the language, and to them everything is easy and understandable.

If the core Red team and main contributors didn't "know everything that comes out of the language, and to them everything is easy and understandable.", that would be very worrying, don't you think so?

> They will fight you to the death if you even try to say that "english-like syntax with no parantheses" is the opposite of readable or understandable when you don't know the system.

Exaggerated, like your whole post. We have civil discussions with people who are actually interested in discussing about Rebol and Red. [1] From the way you sound, I am wondering if you might be one of the few arrogant people who show up on our online channels from time to time, trying to lecture us about "their right way" using a condescending tone...usually, that does not end well.

Fortunately, such bad encounters are rare. We often get lispers showing up from CL, Scheme, or even language authors, like Joe Armstrong (Erlang's author) on our Gitter chats in 2017 IIRC, who liked Red and labelled it a "fun" language. Though, Joe was later upset by our branching into the blockchain world, like a few others in the community, but I hope they see now that we did it for good reasons.

> Go into any of Red's source files and you will end up looking at dozens to hundreds of lines of code with no comments and which often look like this:

    return old-gradient-pen DC cmds start tail cmd sym catch?
    OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
    _read opfd hash alg-digest-size type

Patching together cherry-picked lines of code from different Red/System files, with zero context...how dishonest. (I give a detailed context and explanation about those lines you have extracted from different sources on a separate page [8], as it is quite long. It also debunks your "no comments" claim as the first line you have picked has 3 comments in the neighbouring lines.)

So, you went to cherry-pick low-level code parts in Red/System, involving OS API calls, for what? For making a preposterous statement like "These are obviously impossible to look up and find."?... Those lines of code are not mine, though it took me only a few of seconds using a basic code editor (not even pulling VSCode with the Red plugin) to fetch the information needed to fully understand those expressions...so much for the "obviously impossible to look up and find"...

People are using free-ranging evaluation in Red and Rebol code since 20 years, and readability is not something users complain about (they were certainly many other issues to complain about, but that is not one). On the contrary, it is one of the Rebol features I have found the most attractive, as have many others. I can understand that your mind is not wired for that, and that you don't like it, but that's not a reason for getting angry at us, nor at Red. The sad part is that you don't even bother asking why such design choice was done in the first place, and what is the aimed trade-off behind it...that speaks volume about your real agenda here.

> The whole development is haphazard as well.

Great, another armchair expert on Red! You are obviously not a Red contributor, I doubt you are a Red user either, so you really have no clue about the project's history, nor goals, nor organization, nor its real-world constraints (at this point, I don't think you care at all anyway, you are just here for bashing). Funny how you jumped from a feature of the language syntax to development process. Your post is really not meant to inform anyone, but only to cast negativity over the Red project...for no good reason.

> Everything hinges on two may be three people who know Red internals wihch frantically move from subsystem to subsystem developing features and patching wholes.

Let me rephrase that properly for you: "The core Red team is working very hard, despite being small, on many different sub-systems, restlessly implementing new features and fixing issues, making the Red users and community happier every day!".

So now being a small, but very capable team is something bad? As you praise a pretty much solo-project later, I don't get the rationale there...double standard I guess. Moreover, you don't even know what you are talking about (again). I can count at least 7 people in the Red community, including the core team, capable of working on the Red internals, adding features or fixing bugs. Maybe it has escaped your understanding, but we are building a stack of programming languages (with lot of system programming), and not a web site. The skills and experience required for properly doing such work are very rare. The few capable people also have real-life constraints, so the permanent core team capable on working on the internals is currently 3 people, with additional 2 or 3 more working on their spare time. We are lucky and grateful to have that many capable people with us already. We are still in the early days, with an alpha Red, so having a small compact team is rather an advantage, as there is still significant design to do.

> a fix is written (with zero comments even for the complex issues) and merged

From 10 days ago, ticket #3692 [2] referenced a hard to reproduce complex crash (an heiseinbug), and includes a few hundred lines of detailed explanations about the debugging process, including some screenshots.

I usually only comment some fixes when the explanation or fix is not obvious for the team. Sometimes, the comment is just put in the commit log. Systematically commenting all fixes would be useless anyway, as many fixes are straighforward, or simply don't deserve any comment (like the "Malignant output from react/link" [3] one you've pointed out below). Moreover, we have a strong presence on our Gitter chat, and are always happy to help contributors ramp up when needed. If someone thinks that a particular fix requires a comment or explanation, we are always glad to provide it.

> About 0.001% of "tested" issues contain any tests. The majority of fixes are apparently only fixed and manually tested against the reported issue.

You are implying here that tests for bugfixes are non-existent. Let's put your extravagant claims to the test (pun intended):

- 1076 tickets with `status.tested` and `type.bug` tags [4]

- 52 tickets with the extra `test.written` tag [5]

That gives a 4.83% result...so about 5000 times more than your claim! That's what happens when you are pulling fake numbers out of your ass. Moreover, as you are wilfully ignorant about Red project (confirmed by your other posts), you don't know that:

* the tests are sometimes provided in a later commit (using a `TEST:` prefix in the log), not necessarily within the fix commit.

* some tickets get a test written, but the `test.written` tag is not set (no stats there, not sure how many)

* we do try to address in batches the missing regression tests for fixes, from time to time.

The last point has led to the creation of a specific test file [6] that gathers tests written in those batch sessions. I count 242 more tests there, so it gives a total of 294 written tests for fixes, about 27.3% as the final result. So much for the "0.001%"...

That result is surely not satisfying though, even if 100% is not a goal there, as explained above, we should get a much more complete coverage for bugfixes.

> etc. etc.

Typical ending for a FUD-spreading post... The only honest statement from you I can find is your Twitter account's baseline [7]: "Opinions on things I know nothing about". That sums up well your posts here about Red.

[1] http://lambda-the-ultimate.org/node/1240#comment-48582

[2] https://github.com/red/red/issues/3692

[3] https://github.com/red/red/issues/3713

[4] https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...

[5] https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...

[6] https://github.com/red/red/blob/master/tests/source/units/re...

[7] https://twitter.com/dmitriid

[8] https://pastebin.com/jezLyDVt

8 anni fadiscuss

> * Apparently, it took it 8 years to get simple (in words of author) G.C. [3]

Apparently you didn't look close enough at the history and are making up fake information.

Preliminary work on GC started in 2017 for a month, then resumed in 2018 for about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the runtime library and tracking notoriously hard to catch GC-related issues.

8 anni fadiscuss

By definition, "official" is what is published by the Red core team, on our official channels. We try to support and encourage the efforts of our community members by linking their site from the official Red site. That does not mean that we control nor endorse all the content there.

8 anni fadiscuss

> Never mind that Red is actually implemented in another abandoned proprietary language[0]!

Github's code breakdown by languages for red/red repo:

* Red 83.8%

* Rebol 15.7%

* C 0.2%

* Visual Basic 0.2%

* Java 0.1%

* Shell 0.0%

Only the compiler is implemented in Rebol, the rest, including the interpreter, the consoles, the GUI system and the whole runtime library are implemented in a mix of Red and Red/System. From top of my head, it's about ~25k LOC for the compiler/toolchain (in Rebol) and ~130k LOC for the REPL and runtime library (in Red and Red/System).

The use of Rebol is only for boostrapping the language. The whole Rebol code part will be dropped after 1.0, and the toolchain rewritten in pure Red.

8 anni fadiscuss

> (Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?)

Red's author here. I have nothing to do with those websites nor their content. They are not official Red nor Rebol sites. I do not see a single quote from me there, nor from Rebol's author. Stop spreading false information please.

8 anni fadiscuss

Red's author here. The answer to your question is, I think, that it is just not ready for prime-time yet:

* Language and runtime library are at version 0.6.4, so still alpha stage.

* Lack of support for mobile and web platforms (Android support is coming this year).

* Documentation is largely incomplete, still relying on Rebol docs for core parts.

* Community is very active, but still tiny, it needs to grow much bigger.

8 anni fadiscuss

Thanks for those answers. Let me add something for helping the visually impaired who have troubles reading the Red blog. Here is a simple Red script to retrieve information from the Red blog, then calculate and display (with a color fade-in effect) the upper bound result of the RED tokens sales:

    Red []

    page: read https://www.red-lang.org/2018/01/red-here-we-go.html
    
    parse page [
        thru "Private investors" thru "(" copy angels to ")"
        thru "open rounds"       thru "(" copy public to ")"
        thru "Private Investors" thru "&gt;" copy angels-price to "RED"
        thru "Open round"        thru "&gt;" copy public-price to "RED"
    ]
    angels: to-integer trim/with angels ","
    public: to-integer trim/with public ","
    result: (angels / load angels-price) + (public / load public-price)

    view [
        title "Token Sales Result"
        below
        text 300 "And the (upper) bound sales result (in eth) is:"
        h1 300 center bold beige beige rate 5 data result
        on-time [
            ff: face/font
            repeat c 3 [ff/color/:c: ff/color/:c - pick 4.2.3 c]
            if ff/color = black [face/rate: none]
        ]
    ]

This short example relies on two eDSL, one for parsing data, one for building a GUI. Such built-in features (not requiring any library) shouldn't be that bad for an "incomplete" language, right?

9 anni fadiscuss

There are two third-party reference-like (but non-authoritative) documentations that I know of [0][1]. A Red reference documentation for Parse will be available later this year.

[0] https://en.wikibooks.org/wiki/REBOL_Programming/Language_Fea...

[1] https://github.com/gchiu/rebol.net/blob/master/wikipedia/Par...

10 anni fadiscuss

The 17 LOC version is still relatively readable for someone fluent in Red/Rebol, despite the tight vertical packing. I could have claimed 14 LOC using the minified version [1], but in such case, I couldn't have called it "readable" at all. ;-)

[1] https://gist.github.com/dockimbel/091cc787b366a3d88972b8cb9e...

10 anni fadiscuss

If you want the fully unfolded version you have it there [1]. If you count the JS + CSS lines, then it's about the same size as the Red unfolded version.

[1] https://gist.github.com/dockimbel/b0a413342dc39568696207412a...

10 anni fadiscuss

Red's author here. In all fairness, for that JS spreadsheet to not look ugly, you need to account for the CSS code too, which is ~35 more lines of normally spaced code. Also, there's no realtime reactivity like in our demo where the cells update as you type.

For the "no library", well, you have tons of libraries included in a ~100MB runtime (browser) required to run and render that demo, while Red's one runs on the OS directly (our runtime is 0.6MB uncompressed and entirely written in Red, not a single 3rd-party library). ;-)

That said, that JS demo code is very nice, and its slickness impressive.

10 anni fadiscuss

Goran, congrats for this release and the nice website! It is interesting to see where mixing ideas from Red/Rebol and Smalltalk can bring us to. What are the main pros/cons of using Nim as the underlying language?

11 anni fadiscuss

A polyfill to Javascript is already planned.

https://github.com/WebAssembly/design/blob/master/Polyfill.m...