rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - NaitLee

Pages: 1 2 3 ... 12
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 03:49:07 PM »
This may enough for most others. But in my own case I should consider if srcDir is/can be absolute. ::)

Here is a unix-like environment.
My workdir is at ~/Documents/Tradit-TPL, I just symlinked it to ~/Applications/hfs0.6.0/plugins/Tradit-TPL
This way I don't need to move the workspace around to update hfs. I just create a new symlink to new version.

But when the plugins are imported by HFS/Node, the symlink is resolved by Node,
then my plugin scripts can't import HFS libs with a relative path for/from HFS/Node runtime: nothing is around the real workspace.

And that's why previously there's an "absRequire" thing...

Sure I can define my own development config (as in-plugin debug configs), if I can make everything well by/for myself :)

btw is there any convenient technical methods on Windows/other platforms for developing hfs plugins (or hfs itself)?
If really no, we may implement some in HFS level, to help developers :)

PS. seems my posts are "ignoring" normal users that just cares file sharing. I'll try my best to focus on the main target :)
But, I have much enthusiast to investigate HFS3, plugins, and macros... I want to grow and be well...

A note for passing-by guests: this is an technical topic. For seeking template themes see other topics :)

Administrators: should this be in programmers corner? But this is really relative to template. Remove this note if determined to move/keep :)

HFS3 default frontend is so fast.
But for template makers like me, want to make template useful for both HFS versions (HFS2 and 3)
In my thought it's not the disliked "compatible", but "universal", since there's no reason for a frequent casual user to leave away from HFS2.

Now I am making a plugin for the new HFS3 to support "traditional" templates.
Macros are there for HFS2.3 to implement useful logics, making a (dynamic pages based) template more "smart".
I've already made it to parse macros in PHFS. But if you tried using it you can find it's very slow, compared to Delphi HFS2.
Yes, Python itself is slow in these basic operations like string batch,
but there are other reasons, including every time we request a section it parses through the raw strings again and again, even if the macro procedure is fixed.

I want to make things faster. Though may still slower than pure-ajax, I want to try my best, at least for skill practicing :)
I'm thinking about serializing macros to make least waste in each execution/evaluation.
And, after this, macro injection (attack) will never work, even if there's an entrance for such action.
As for now I got some ideas, stated below, in normal text and/or source code (with comments)...

Some concepts are made:

MacroSegment and MacroUnit
These will nest some instances of each other to make the macro procedure clear & easy for computer.
Get more details in the code snippets below. Be prepared for thinking :D

MacroContext and MacroContextGlobal
These are for storing eg. variables, and stack for "liner macro execution"[1] (more info below)
Code in snippets may be modified to add more things.

MacroExecutor and MacroExecutors
For defining static functions to execute macros. A MacroUnit have an executor attribute assigned to one in MacroExecutors.
This may change to getter/setter in the future, to support "dynamic executor"[2]

Also see Footnote, FaQ, and Trivia, at the end of this post :D

Some (TypeScript) code snippets, for description: (may be modified at any time)
Code: [Select]
class MacroContextGlobal {
static globals: Record<string, string> = {};
static cache: Record<string, string> = {};

class MacroContext extends MacroContextGlobal {
variables: Record<string, string> = {};
stack: string[] = [];

interface MacroExecutor {
(ctx: MacroContext): MacroResult;

class MacroExecutors {
[key: string]: MacroExecutor;
// ...

var macroExecutors = new MacroExecutors();

 * A "part" of the whole macro expression, like a quote block, or a piece of string as argument of a macro.
 * A `MacroSegment` can be *evaluated*, to produce a plain string, then send to client / put into `MacroUnit` args/kwargs.
 * The term *evaluate* can be understood as original *dequote*, if there are items in `execOrder`.
 * In a section there's a root `MacroSegment`. 
 * Concepts:
 * - `segOrder` and `execOrder`:
 *   - Macros are mixed with plain parts and executable parts,
 *     for result production, we first take a sub-segment from `segOrder` as text,
 *     then, we take a `MacroUnit` from `execOrder` then execute it, finally get text.
 *     By repeating until last `segOrder`, we complete.
 * - `isPlain`:
 *   - For marking current segment as plain, i.e. no need to be executed.
 * - `isAlias`:
 *   - For marking current segment as alias from `[special:alias]`
class MacroSegment {
segOrder: MacroSegment[] = [];
execOrder: MacroUnit[] = [];
isPlain: boolean = true;
isAlias: boolean = false;
constructor() {}

 * A part of the whole macro expression that have specified function, as a macro block. 
 * A `MacroUnit` can be *executed*, for performing special operations.
 * Concepts:
 * - `executor`:
 *   - A kind of callable that can be found in class `MacroExecutors`.
 * - `args`:
 *   - A list of arguments, as `MacroSegment`.
 *     They **may** be dynamically *evaluated* by individual `MacroExecutor`.
 * - `kwargs`:
 *   - A list of keyword arguments, always optional, indexed with string, also as `MacroSegment`.
class MacroUnit {
executor: MacroExecutor = macroExecutors._unknown;
args: MacroSegment[] = [];
kwargs: Record<string, MacroSegment> = {};
constructor() {}


[1] "liner macro execution"
Let's consider an example:
The normal way is to walk from start, see the most-inner macro, pick up, execute, then replace it as result, then do again until end...
But in our way, after serialization, instructions are ordered there one by one:
execOrder = [ mul, add ]; (pseudo code. note that these are MacroUnits, which wrapped both an executor and arguments (as nested MacroSegments, plain or evaluatable))
... after the "mul" unit executed, it's result is pushed to stack of current MacroContext, then in "add" unit we leave a mark to let it shift one element from the stack as an argument.
This is mind-exhausting, but computer is really doing effective liner action.

[2] "dynamic executor"
Another example:
I think most dynamic language developers have tried such method to determine which function to use. :D
(wantSub ? sub : add)(5, 3) (sub and add are functions)
While it just works, it may confuse a static computing rule.
So our MacroExecutor need to be dynamic at here, by making the executor attr a getter.

= Why don't publish source code now?
- The source now only contains these "ideas" and completely not usable. It takes some time to integrate this large scale.
= Well... where will the source code be?
- On here of GitLab. But it's empty now.
= What's wrong with GitHub?
- Here have trouble accessing it, ranging the whole mainland region. Successfully viewing is by luck.
= Mirror to GitHub?
- I'll consider/try when the project become active.

I scribbled on my note paper in order to understand all of these by myself.
The workstation for this project is on a new laptop with Manjaro GNU/Linux, for playing with edge-technique stuffs.
I didn't want to touch Node.js, until I want to work on this. :)
The source code is full of typo "executer" before I post this. :P
I'm trying out Tabnine, an AI assist for coders. It auto-completed many pieces of code here. (Note: no advertisement meanings at all, but may help)

HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 12:42:55 PM »
ok, let's try to keep plugins "subjective"...

Now that apis for a plugin are manipulated by HFS, and many more sooner-or-later,
so whether a plugin is ready is determined by HFS.
Why doesn't HFS finally tell the plugin is ready? it is as easy as calling init() on the plugin module, if there is one.
Of course the procedure of init() is by plugin developers :) seems better than a mysterious setTimeout thread trick
I accept the "exports.api" if this kind of objective-or-subjective is dealt well :)

Also consider asynchronously initialized plugins. Await one of it's the case and it's necessary.
Consider telling HFS it's async / should be awaited (or other characteristics) by exposing something (like isAsync: true) in module.exports.

I think we still need to tell plugins where are builtin files, for edge cases.
Even if it means "at my own risk" or "not officially supported", it's a way to play with HFS in a kinder method.
Of course we can limit it with something like debug flags... Just in completeness.
... If really still don't want to do this, just omit these :D

btw I choose to import builtin files (as a fallback layer of exports.api) for now for my tpl plugin, for maximum efficiency of development & test cycle

HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 09:34:17 AM »
Some random thoughts... :)

I see this:
Code: [Select] = data = { }

While I can understand changes to plugin, this "cloning" may not as good as think.
It's better to consider the "prototype" in JavaScript.
Again about the "api injection" technique, consider other acceptable methods :P

Also before HFS 0.6, there's this in my tpl plugin:
Code: [Select]
var traditTpl = function(ctx) { template.serve(ctx); return true; }
traditTpl.prototype.middleware = function(ctx) { template.serve(ctx); return true; }
// ...
module.exports = traditTpl;
I just think it maybe useful, so wrote this by casual. And hfs 0.6 really want a "middleware" attribure.
But this didn't work -- the object cloning doesn't clone the prototype.

... Wish these make some sense :D

Tip: manipulate prototypes with Object.setPrototypeOf(target, object) etc.
PS. I don't afraid of changes. I just want to keep usual practice and keep things as-good :)

HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 06:04:04 AM »
The ISP here seldomly allows me (and other people) to access GitHub, whether I can access HFS repository is by luck.
If possible please mirror the repo to somewhere like GitLab, then ones here can have another way...
GitLab can also be self-hosted.
I'm moving to GitLab also.

I see the directory structure changed.
But it made me confused: should I access HFS libs by simply importing the original files?
In the last 2 days I structured my tpl plugin (with/for hfs 0.5), it uses this:
Code: [Select]
import process_1 from 'process';
import path_1 from 'path';

// Workaround for my workspace, which is symlinked to plugin directory.
const NODE_PATH = process_1.cwd();
export function absRequire(path: string): any {
    return require(path_1.join(NODE_PATH, path));
This is used to solve many things, with absolute cwd.
And with it I am able to import HFS libs, and use them directly.

While we are exposing some apis in another way (like the const api = exports.api = {}), which means we'd better just use it.
But in theory it's always not enough, and if there's something missing, I will directly import HFS libs then use stuffs inside, without nothing bad.
This way such exposing became useless :'(

In my case:
Code: [Select]
import { absRequire } from './absRequire';
const frontEndApis_1: HFSFrontEndApis = absRequire('frontEndApis').frontEndApis;
const config_1: HFSConfig = absRequire('./config');
These are before hfs 0.6. They work just well.

So the suggestion is, simply make HFS libs themselves useable in a standard way, then let plugin makers take knowledge from some kind of documents (or source code)
EDIT: "including" the built-in stuffs to a central lib is also an option, and this can keep interfaces stable (not suddenly changed in the future)

PS. I personally feel the exports.api with setTimeout uncomfortable. So I don't want to use it :(

HFS ~ HTTP File Server / Re: a new beginning...
« on: January 08, 2022, 09:04:15 AM »
The middleware plugin feature is completely well... ;)

... But before I success I encountered a bug:
The function deleteModule in plugins.js is recursive,
but when a plugin have requires to Node/HFS native modules, a infinite recurse occurs.
Code: [Select]
plugin error importing test.js RangeError: Maximum call stack size exceeded
To reproduce, a single "require" to HFS native module in a valid plugin can trigger this.
So, only do recurse if it's a real "plugin" (or really need be deleted) and not deleted before.
(found this after debugging for half an hour :()

And, consider a event-driven plugin structure? We can do almost everything with dom addEventListener, and also event.preventDefault :)
Don't forget the old "event script", too :)

HFS ~ HTTP File Server / Re: a new beginning...
« on: January 04, 2022, 02:32:02 PM »
thanks for reporting the quick*.js problem. I reuploaded the release so that it's fixed.
Can you tell me why you removed the icons file ?

The lower-cased "quick" is found in 0.4.0. Also fix that :)
Oh right, all google services are banned in my locale, including the search engine, its resource api/cdn, and captcha...

For those that need HEAVY customization, totally replacing the "frontend" folder will be an option.
Anyway, that should be the last option. Let's try to focus on customizing the default frontend without touching it.
Tell me what you would like to customize exactly.

Yeah, this inspires me to go deeper... ::)
My goal is to make "old" templates (of HFS2) to be able to be used in this brand new version.
Because this project will develop in time, but the Delphi version will still have audience for a long time.
Why don't just cover them both :D
I don't like the so-called "compatibility" either. But this time it's not "compatible" but "universal", right ::)

So here it comes: the "Tradit-TPL" plan, it aims to add a layer to this new version to support legacy templates.
In attachment there's a WIP version that can do sections & few symbols. Of course macros are on-the-way.
It uses some concepts from PHFS. So we can just walk toward :D
Read the readme in archive and follow it to try.
If have no interest in it, just let the community take the job. :D

PS. Dynamic page and Ajax have different pros & cons. Selection is by one's preference.
PPS. I personally want to renew the development of my template but keep one codebase and some traditions of Throwback.

While making above work, I've found a possible bug in `frontEndApis.file_list`:

Argument `sse` is directly from url query, so it's string. Even when we pass `?sse=0` it is still true.
So may convert it to number along with `offset` and `limit`.


HFS ~ HTTP File Server / Re: a new beginning...
« on: January 01, 2022, 04:20:27 PM »
Few obstacles here in testing, but overall great ;)

OS: Manjaro
Environment: Node.js v17.2.0
Browsers: Firefox 96.0b3, Chromium 96.0.4664.93

Since exe is not needed here, I just take the from release.

First node complains cannot find module './QuickZipStream'.
Seeking around, and found there's a quickZipStream.js in root folder.
So in filesystems like ext4 filenames are case-sensitive. Be aware of that :D

By correcting the letter-case and specifying a port (other than 80), it started successfully.

Then a google stuff stalking around:
Code: [Select]
<link href="" rel="stylesheet" id="iconsFile">
By blocking the request, the list loads blazing fast.
And, seems there's missing a CSS rule: #root { margin: auto; } ::)

By adding home folder to config.yaml, it is listed. There are many items, but listing is still that fast.

Without icons loaded it looks silly (for the long alt duplicate strings). Wish there can be a better (local) approach.

By the way, it is almost impossible for a normal user to edit the 244kb minified javascript to fit normal/special needs. Starting from source is tough.
... Yes I'm thinking about template again ::) no need to think too much, just go with our own pace :D

HFS ~ HTTP File Server / Re: a new beginning...
« on: January 01, 2022, 06:50:37 AM »
Wow, great... :D

I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.

I kinda like the Lisp-ish syntax, hacking around it makes fun. But others may don't think so...

Making a template engine based on other stuffs is well acceptable, as well as the community develops :)

If this is the case, please open some API or Plugin interfaces (at any time), thus we can make an interpreter for old templates...


Bug reports / Re: How to delete files.
« on: November 17, 2021, 05:14:49 AM »
It's just another problem of HFS 2.4 default template, and the direct fix is stated in a GitHub issue/forum report. (see below)
Also, switching to another template (with working "delete" function) can help.

Choices are Takeback and Mobil-light. You can find them in Template sub-board :)

I think @NaitLee or @Danny already reported a similar this error (I can't remember).

... I think it's dj found this bug first ::)
The GitHub issue:
There is maybe one/some report(s) in Beta sub-board too :D
(ps. see dj's post here. this post is a bit later than that, but started editing before that)

Also, rejetto... For this whole year, the only time he speaks here is to celebrate my birthday... :'(
Now the cake is in his profile now... :D 🎶 Happy birthday to you 🎵, rejetto :D

so changing system code page will not solve this.

Yes, this only works with "common" encodings, such as Chinese & Japanese, but not Thai.
Use HFS 2.4 if possible ;)

In my test, after changing code page to Thai, a folder named "อรุณสวัสดิ์" can be put into HFS 2.3, but the URL Encode result (which should to UTF-8) is incorrect.

According to further test, these are the conversion steps of HFS 2.3 (or Delphi without Unicode):
- Windows think this program cannot understand UTF-16 (the filename encoding of NTFS) and converts that to ANSI Thai "code page": TIS-620
- HFS 2.3 regarded this TIS-620 raw data as GB2312 encoded
- Then convert the raw data to UTF-8 with GB2312 map
which will succeed the action but get wrong data :P

So this problem cannot be solved in 2.3 unless we have a hack in the old Delphi, add the TIS-620-to-UTF-8 map, be sure it will be correctly used, then re-compile...
Too complex then just upgrade to HFS 2.4 :D

Ps. encoding test can be done with Notepad++ on Windows, or any good editor on GNU/Linux. Also the command-line utility "hexdump" can show you the true raw data of a file.

HTML & templates / Re: The "Takeback" template - A different & modern taste
« on: November 10, 2021, 12:43:18 PM »
I sent you a PM with more details :)

Now it's obvious... :D So I should explain the two "Archive"s again

"Archive" is not "Download". While they both give users files, archive means to bundle all/selected files together, while download usually means only one file.

Also, have a look again at my previous message, especially the explanation after the 2nd quote.
Now you know there's 2 different "Archive"s, and the second one is which you need. It appears after selecting items, on the preview panel, as underlined brown text.

So you shall modify the note for users, say that they need to "download" selections with "Archive" on the preview panel ;)
... Or for a better approach, put this in HTML/CSS:
Code: [Select]
#preview > div:nth-child(3) > a:nth-child(5) > span:nth-child(1) { color: cyan; }
.part2 > p:nth-child(1) { display: none; }
These CSS highlights the correct "Archive" and removes the incorrect one.
( be sure to modify anything to fit exact needs )

HTML & templates / Re: The "Takeback" template - A different & modern taste
« on: November 10, 2021, 11:09:28 AM »
I have a small problem with this
I share albums and if i try to download a single track from an album it then downloads the whole album
Love the layout though
Any help would be appreciated
Thank You

Glad to hear feedback :)

Please give more info of that problem, such as:
- What action did you do for downloading? Maybe it's the cyan "Download", the "Archive" at page bottom, or the brown "Archive" after several selection...
- What is the form of an album and tracks? Are they appear as files inside a folder, or just one file, or a .m3u(8) file?
- ...

Good luck :D

Except, when you click "Archive", you will get a "*.tar" file containing only files shown in the list, but not folders.

It's about the "?recursive" parameter in the url ("urlvar"). When it is there, the sub-folders will be included, and will not otherwise.

In the case of Takeback (and also Throwback), this parameter is not included in the "Archive" at page bottom.
Rather, in Takeback, it's included in "Archive" action when doing multiple selection of files/folders. So, if you select all items and do "Archive" in the preview pad, the archive will be full :)

Yes, it's not easy to discover. May choose an alternative method in future.

Firstly, your Windows system language is English, which means that the "code page" is maybe also English-only.
As HFS 2.3 is non-Unicode, you should change the system code page to Thai (or relative) -compatible, then the problem may be solved.

Here's a related link, all answers inside are helpful.

After changing, please re-launch Windows & HFS and put the folders again.

( many terminologies here  ::) search the web for more information )

Then, if above didn't work, may try HFS version 2.4, which supports Unicode. Find its development/download link in "Beta" sub-board.

Last note: HFS 2.3e is an insecure & vulnerable version. Switch to 2.3m or above if possible ;)

中文 - Chinese / Re: 在找 HFS 的中文资源吗?在这里哦 ;)
« on: October 25, 2021, 01:35:44 AM »
HFS 2.3 里的好多字符串都是写死在代码里的,不能通过翻译文件更改。
HFS 2.4 很好地修正了这个问题。
如果需要完整的翻译,建议使用 HFS 2.4 版本:
它还在 RC 阶段,不是很稳定。可能需要在这里找找更多的资源和帮助。
…… 这里好多有意义的资源都是英文的 ::) 有不懂可以随时在这里问 ;)

Pages: 1 2 3 ... 12