Sponsored Content
Top Forums Web Development Notes with Ravinder on Badging System Development Part II Post 303028268 by Neo on Thursday 3rd of January 2019 07:22:04 AM
Old 01-03-2019
Update:

41 of 48 prototype badges done, or 85%.

Ravinder is working on the logic for a "consecutive days or forum activity" badge, which sounds cool, so that would be number 42 I guess, which will leave 6 "Reserved" badges left to do.

If one of those "Reserved" badges is allocated for the the mod system of member ranking; then that means:

Code:
41 Badges Done
1 Badge Under Development (Ravinder)
1 Badge for Mod Scoring / Points (Reserved)

This is real progress in a relatively short time.

If anyone has an idea for a badge, please post!

Thanks.
 

3 More Discussions You Might Find Interesting

1. What is on Your Mind?

New Badging System - Badges Prototype Beta 1 (Badges Only)

Today I mapped out the new badging system using FA icons, Beta 1 in no particular order except a 6 x 8 grid: https://www.unix.com/members/1-albums215-picture991.png The prototype HTML code for this layout: <style> .fa-badge-grid { font-size: 1.5em; } .row { ... (38 Replies)
Discussion started by: Neo
38 Replies

2. What is on Your Mind?

Status of Badging System - Beta 1

Dear All, Here is the current status of the badging system: The Beta 1 phase of the new badging system is close to completion. 42 prototype badges have been "allocated" 6 prototype badge slots are held in reserve The "alert you have new badges" prototype is running and is currently... (4 Replies)
Discussion started by: Neo
4 Replies

3. What is on Your Mind?

Badging System: UNIX.COM Bug Hunter Badge (New)

I have moved the bug badge out of reserve and into the main stream. Basically, I will assign a color level like the others, based on who has made a good actionable bug report for UNIX.COM. "Good" means screenshots, links, and even details from web dev tools our the HTML source code. So far,... (0 Replies)
Discussion started by: Neo
0 Replies
script(5)							       Files								 script(5)

NAME
script - Boot script DESCRIPTION
The boot script describes how the Erlang runtime system is started. It contains instructions on which code to load and which processes and applications to start. The command erl -boot Name starts the system with a boot file called Name.boot , which is generated from the Name.script file, using sys- tools:script2boot/1 . The .script file is generated by systools from a .rel file and .app files. FILE SYNTAX
The boot script is stored in a file with the extension .script The file has the following syntax: {script, {Name, Vsn}, [ {progress, loading}, {preLoaded, [Mod1, Mod2, ...]}, {path, [Dir1,"$ROOT/Dir",...]}. {primLoad, [Mod1, Mod2, ...]}, ... {kernel_load_completed}, {progress, loaded}, {kernelProcess, Name, {Mod, Func, Args}}, ... {apply, {Mod, Func, Args}}, ... {progress, started}]}. * Name = string() defines the name of the system. * Vsn = string() defines the version of the system. * {progress, Term} sets the "progress" of the initialization program. The function init:get_status() returns the current value of the progress, which is {InternalStatus,Term} . * {path, [Dir]} where Dir is a string. This argument sets the load path of the system to [Dir] . The load path used to load modules is obtained from the initial load path, which is given in the script file, together with any path flags which were supplied in the command line arguments. The command line arguments modify the path as follows: * -pa Dir1 Dir2 ... DirN adds the directories Dir1, Dir2, ..., DirN to the front of the initial load path. * -pz Dir1 Dir2 ... DirN adds the directories Dir1, Dir2, ..., DirN to the end of the initial load path. * -path Dir1 Dir2 ... DirN defines a set of directories Dir1, Dir2, ..., DirN which replaces the search path given in the script file. Directory names in the path are interpreted as follows: * Directory names starting with / are assumed to be absolute path names. * Directory names not starting with / are assumed to be relative the current working directory. * The special $ROOT variable can only be used in the script, not as a command line argument. The given directory is relative the Erlang installation directory. * {primLoad, [Mod]} loads the modules [Mod] from the directories specified in Path . The script interpreter fetches the appropriate mod- ule by calling the function erl_prim_loader:get_file(Mod) . A fatal error which terminates the system will occur if the module cannot be located. * {kernel_load_completed} indicates that all modules which must be loaded before any processes are started are loaded. In interactive mode, all {primLoad,[Mod]} commands interpreted after this command are ignored, and these modules are loaded on demand. In embedded mode, kernel_load_completed is ignored, and all modules are loaded during system start. * {kernelProcess, Name, {Mod, Func, Args}} starts a "kernel process". The kernel process Name is started by evaluating apply(Mod, Func, Args) which is expected to return {ok, Pid} or ignore . The init process monitors the behaviour of Pid and terminates the system if Pid dies. Kernel processes are key components of the runtime system. Users do not normally add new kernel processes. * {apply, {Mod, Func, Args}} . The init process simply evaluates apply(Mod, Func, Args) . The system terminates if this results in an error. The boot procedure hangs if this function never returns. Note: In the interactive system the code loader provides demand driven code loading, but in the embedded system the code loader loads all the code immediately. The same version of code is used in both cases. The code server calls init:get_argument(mode) to find out if it should run in demand mode, or non-demand driven mode. SEE ALSO
systools(3erl) Ericsson AB sasl 2.1.9.3 script(5)
All times are GMT -4. The time now is 09:30 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy