Nim 1.0

[juancarlospaco]

• https://github.com/nim-lang/Nim/commit/5b43c98897ee7eb9f8ded8ceb7623f6caa23bace
• Compile-Time optional PackedJSON for Performance (only changes import json) https://github.com/Araq/packedjson#packedjson

A new update cycle :slightly_smiling_face:

[juancarlospaco]

I want to move static const very long strings out of code, because it makes it look like code is huge when is not, and static const strings we rarely touch.

I will move static const into a separate "dedicated" constants.nim.

[ThomasTJdev]

Nice work @juancarlospaco!

I was thinking about adding a small License block in our README - or a explanation inside the License.md (?). The PPL is new to many, and can push people away. Something like your responses on the old issues:

[TLDR PPL](https://tldrlegal.com/license/peer-production-license)
The Peer Production License (PPL) is derived from the Creative Commons ‘Attribution-NonCommercial-ShareAlike’ license. However unlike CC-BY-NC-SA, PPL demands reciprocation (whether monetary or otherwise) from non-contributing commercial entities (aka Big Corporations). This means, that a mega-corporation cannot just take all the code, rename it, and sell it without contributing back.

The Peer Production License is a reciprocity-based license by which commons are freely accessible to those who contribute to create them, while third party non-contributing entities profiting from these commons can be charged a license fee to sustain the project in the long run.

Besides the above, a explation, bullet list or FAQ for:

• If you are a independent developer, you may: Use it xx
• If you own a software company, and the company helps with PR's, you may: Use it xx
• If you own a company, which wants to use NimWC to provide free website to it users, you may: Use it and pay
• May I use NimWC (without editing) as my webpage, where i sell products?
• May I use NimWC (without editing) with my own plugin, where I sell the service my plugin provides?

[juancarlospaco]

The same file layout I did with the constants.nim I will try to reorder the internal modules, the reason is to reduce the I/O unneeded repetition when reading the configs again and again, for performance and DRY, besides constants look nice now.

[juancarlospaco]

From inspecting the generated code of the *.nimf:

• They wont need # result = "" inside the function anymore, that was when string was nil.
• Can be func.
• Can be {.inline.}.

I am beautifying the *.nimf.

[ThomasTJdev]

From inspecting the generated code of the *.nimf:

• They wont need # result = "" inside the function anymore, that was when string was nil.
• Can be func.
• Can be {.inline.}.

I am beautifying the *.nimf.

Wow - great catch! :+1:

[ThomasTJdev]

Idea: style.css and style_custom.css should be merged into 1 file avoid 2 file request (also JS)?

[juancarlospaco]

• Add proc getConfig(path, section) to get a Table of configs, to DRY reading configs.
• Add --version-hash to show Version (Git Short Hash).
• Add --backuplogs Compressed full backup of all old unused rotated Logs. Makes all ./logs/*.log :arrow_right: logs-ISODATETIME.tar.gz. :slightly_smiling_face:

[juancarlospaco]

Too much run-time encodeUrl("foo bar") on the routes.nim, I will try to move those into constants.nim, because they are static string can be compile-time.

:thinking:

[juancarlospaco]

routes.nim

get "/sitemap.xml":
    writeFile("public/sitemap.xml", genSitemap())
    sendFile("public/sitemap.xml")

Here writeFile("public/sitemap.xml", genSitemap()) needs to be run and re-write the file on each request :grey_question: Or we can wrap it on a once: so it writes the file once per run :grey_question:

If needs to run on each request, it needs to be written into a file :grey_question: Can just resp genSitemap() :grey_question:

:thinking:

[ThomasTJdev]

routes.nim

get "/sitemap.xml":
    writeFile("public/sitemap.xml", genSitemap())
    sendFile("public/sitemap.xml")

Here writeFile("public/sitemap.xml", genSitemap()) needs to be run and re-write the file on each request Or we can wrap it on a once: so it writes the file once per run

If needs to run on each request, it needs to be written into a file Can just resp genSitemap()

Yeah, I know. When a user is publishing a lot of new blogpost, it's nice to have the sitemap.xml updated, but the downside is the IO. We can make a update-proc which is runned on: 1) startup 2) blog creating 3) blog updating 4) page creating 5) page updating

This way the user does not need to remember to update the sitemap or restart NimWC.

[juancarlospaco]

Ok, then it makes sense to update it, my question was if it can be compile-time constant.

[juancarlospaco]

@ThomasTJdev Review and let me know any comments or push the change to the branch directly. :slightly_smiling_face:

[ThomasTJdev]

Great @juancarlospaco :smiley: !! What are missing before a merge?

[juancarlospaco]

I fixed the backup of logs to put .tar.gz on /logs/.

Postgres works. A clean nimble install works. autoinstall.sh works. Tested on 2 PC.

The autoinstall looks great.

[ThomasTJdev]

New release is ready: https://github.com/ThomasTJdev/nim_websitecreator/releases

I'll start on the plugins, they all need an upgrade due to the refactoring.

[juancarlospaco]

Dont forget the Live Demo too.

I know that it breaks plugins, but was a refactor to reorder stuff that was kind of long delayed, now the folder structure kind of makes sense, and is easy to navigate for new people, looks better.