problem-solving VS chroma

Supply blocks may reorder flow of execution #364: solved Deadlock in supply / whenever chain #5141: fixed Simplify Supply / whenever processing order #5158: superseeded Fix rare deadlocks during supply setup #5202: merged 2023-11-24 Switch Supply.zip to a watermark approach (https://github.com/rakudo/rakudo/pull/5211rework) #5211: merged 2023-03-09 Test supply setup with a blocking recursion #833: merged 2023-11-24

I'm more leaning towards the former. you could open an issue at https://github.com/Raku/problem-solving/issues so that it won't get forgotten.

A bunch of people really good at bikeshedding took over the conversation and by the time they were done, the language looked nothing like Perl and they decided to rename it after the butterfly.

Now, there are security issues with the "p6c" ecosystem, as one can change the contents of a module without a version bump (aka without anybody noticing). So the plan is that the "p6c" ecosystem will be disabled by default.

Either way, I posted the other day a problem solving issue on the topic. I think we should start looking into ways to properly supporting the mixed grammars, be it a trait-like thing (you've basically made a trait without being a trait), a token (like mine) or some other specialized regex syntax.

There was no admitting to themselves.

There was the personal realization that the two factions in what was then the Perl community, would never see eye to eye on what the language called "Perl 6" was. And that all of my efforts of reconciliation, such as the Perl Reunification Summit http://blogs.perl.org/users/gabor_szabo/2013/02/perl-reunifi... had been in vain.

Which lead me to open an issue https://github.com/Raku/problem-solving/issues/81 which in the end resulted in the rename to the Raku Programming Language https://raku.org .

The CALLER:: initiates a symbol lookup in the caller. The MY:: limits that lookup to just the caller's lexpad. This is confusing. cf Particular scopes of PseudoStash'es are not clear #294.

Over time, most of the features that were a selling point for Data::Record have been rendered silly. Namely, the idea of a Tuple and Dict in core has been tossed about since writing, and the introduction of type inference for lists into core leaves most of the collections as which Data::Record is defined (Data::Record::Tuple, Data::Record::List, Data::Record::Map) with the odd edge case to cover, of which I don't feel it does a very good job of in its current release's state.

On my patrol of the wrongly named Discord channel #raku-beginners (I'm a Raku beginner since 2008, so this name is redundant), I spotted once again the question of iteration on nested Hashes and Arrays. Since the HyperWhatever wasn't taken yet (not everyone wants the colon) I wrote a proposal. I'm not sure if my nqp-foo is sufficient but I might give it a shot anyway. Unless lizmat wants to micro-optimise code that has not been written yet.

In Hugo and its built-in Chroma syntax highlighting, a code block begins with:

Hugo -> goldmark -> goldmark-highlighting -> chroma

I've used a markdown to html converter to convert my blog posts into HTML with very nice and customizable code samples... in my case I used Go's Blackfriday library with bfchroma[1] doing syntax highlighting with Chroma[2]. To add your language to Chroma you have to provide a lexer, which in turn is written in Pygments[3] syntax.

[1] https://github.com/Depado/bfchroma/

[2] https://github.com/alecthomas/chroma#supported-languages

[3] https://pygments.org/docs/lexerdevelopment/

quick for generating Html and syntax highlighting code blocks

Chroma

For books from other publishers, I am just hardcoding language directly on an ad hoc basis. I briefly considered off-loading language detection to a library like chroma, but that might be too much work for little benefit.

Great blog, you should definitely do research on how you could implement a syntax highlighter for the code parts. Go Hugo for example, uses Chroma. Nice work 👍