3,050,494 events, 1,601,530 push events, 2,484,399 commit messages, 176,011,648 characters
Windows Release CI
Tweaks
Steadily learning more about the MSBuild setup
Maybe this will work
Hey, don't reinvent the wheel
Maybe this'll work?
Wee again
Weird syntax but maybe
Is the QT install wrong?
Oh, whoops, still wrong version
Thanks qsettings2json
Oh that was an important part..
Oh that was just for VCVars
Attempt to build libgit2
Whoops
Maybe relative paths are less painful for once
Finally cave and modify release_fritzing.bat
We're getting clooooserrrr
These paths are gonna drive me mad
BEH PATHS WHY
My head hurts
Even my debugging statements cause errors
That sorta answers my questions (no it doesn't)
So does this get the stupid folder structure I need or not
So this SHOULD at least find libgit2
Need boost...
Should not need boost
Fix from actions/runner-images#754
Also add libgit2 cache
is the fucking boostdetect pri script broken?
I swear to fuck
Revert changes to boostdetect, test downloading boost
ugh i hate powershell
If the problem was actually this entire fucking time that I didn't check boost I SWEAR TO FUCK I WILL
I am legit pissed
Do it again but release this time lol
Change to artifacts instead of releases
Update to v0.8
A new update is here!
- New skills are available!
- Taunt - Stand still and provoke your foes, earning a small boost to STR/SKL. Gives a big bonus to a Devil Hunter's combo score!
- MAX-Taunt - Double the risk of a regular taunt, but with double the rewards! Go for it all and reap the rewards of style!
- Seal DEF/MAG - Reduces a foe's DEF/MAG by -20 when attacking. This debuff cannot stack.
- Seal SPD/SKL - Reduces a foe's SPD/SKL by -20 when attacking. This debuff cannot stack.
-
A new weapon is available!
-
Yamato: Grants the exclusive Assist skill [Judgement Cut]! Focus yourself and gain power, then unleash it on your foes in one strike!
-
The Battle Forecast has been added.
- During combat, a small window will appear on the right side of your screen. This is called the Battle Forecast.
- The Battle Forecast will relay the combined stats of your current foe during combat (including any buffs/debuffs).
- The foe's highest stat will be displayed at the top of the list.
- Salindrum (training mode) has been overhauled!
- Fine-tune how much damage you deal and receive with the new damage modifiers. Nullify your damage output to practice combos, or aim for perfection with a massive incoming damage boost.
- Repair all of your equipment on the fly, right from the menu.
- Need to borrow some equipment? Try out the new Supply Crate with everything you could need.
- You can now toggle the hunger meter, so you can spend less time eating and more time training.
- The training arena has been remade with a higher ceiling, platforms, and light obstacles for a more versatile training experience.
- Some bugs have been fixed as well!
- Fixed multiple bugs relating to custom projectiles hitting blocks (fake arrows are now properly destroyed when they collide with a surface)
- Fixed some issues relating to cutscene & follower NPC kill credit.
- Fixed issues relating to various C-Slot skills not applying properly.
- Buffed the base might of all magical spells.
- Adjusted spell cooldown timings so that they more closely follow the displayed number on-screen.
Enjoy the update, crusaders!
NOTE: This update targets Skript 2.4-beta8. Regressions have undoubtedly occurred, mostly relating to chat-based menus. These will need to be found and fixed over time.
THATS RIGHT BAYBE MULTI WINDOW SUPPORT
YOU CAN NOW CONTROL MULTIPLE WINDOWS HAHAHAHA FUCK YOU
Provide a permissive license
While the basenn software distribution abides by the GNU GPLv3+ license, the project does use a lot of code snippets here and there to keep things running. However, such code snippets are small enough such that having them under the GNU GPLv3+ license is just overkill.
Since this package is placed onto GitHub, it can be accessed internationally, but the concept of the public domain does not exist in certain countries (Germany being a good example). so, placing these code snippets in the public domain can cause legal issues for forign contributors.
The license that comes close to placing these code snippets in the public domain is the DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE version 2 by Sam Hocevar. Hence, why a copy of this permissive license is being commited.
However, additional clauses such as a non-warranty and non-liability will be added to various code snippets of the package, because the WTFPL does not include them.
- Fixed up React_CreateElement hook, for BaseTable, to not add duplicate columns.
- Tried to implement Import button, using react-vmessagebox, but hit issue of esmodules not being supported in electron.
For esmodules point, I read this thread: electron/electron#21457
Comments at end (eg. electron/electron#21457 (comment)) seemed to indicate you could use dynamic-import calls; however, from my own tests (in lf-desktop), I found that even with latest electron (v12 beta-5), the dynamic-imports only work for the initial file that electron is pointed to. Dynamic-imports from console, event-handlers, etc. always have a "Failed to fetch dynamically imported module" error.
There was also the old solution of using the "esm" module, but apparently that approach stopped working in Electron 10+ (electron/electron#21457 (comment)). Comment suggests the "esm" module/transpiler works again, if you remove the "type:module" field (presumably using .mjs extensions instead), but I don't want to do that.
Thus it seems that, for my code's pathway (as a nuclear plugin, called through eval), there is no way to use esmodules right now.
By the way, the above is all based around the idea that importing esmodules from commonjs modules, requires the async-function wrapper. This is because esmodules are allowed to contain "top-level awaits". Despite the great majority of esmodules not using this, this feature makes it impossible to reliably have commonjs "require" (synchronously) an esmodule file.
See these for background: Overview) https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1 Discussion) nodejs/modules#454
My opinion aligns with the overview article's author, that NodeJS (and by extension Electron) should allow commonjs to just "require" esmodule files -- but that if that esmodule tree contains a "top level await", then an error is generated.
However, as of now, that idea doesn't seem to have picked up much momentum, so it's unlikely it would get implemented any time soon. Thus, we have to fall back to the only existing cjs->mjs approach, of an async wrapper. Which electron (even latest versions) only supports for the module-tree pointed to at electron launch...
Thus, for now (and the foreseeable future), esmodules will not be possible within this nuclear-vplugin package...
My options are thus:
- Avoid use of esmodules, by extracting needed code blocks from those libraries, or using different libraries. (what I'm currently during, through FromJSVE, and using something like electron-prompt instead of react-vmessagebox)
- Use a bundler like Webpack to convert esmodules into a simple bundle (or a set of commonjs files). (I think the "esm" transpiler thing fits into this category, just doing so seamlessly/magically -- however, the magic appears to not work so well in the latest electron versions, as mentioned above)
- Avoid use of esmodules, by updating your libraries to not output esmodules -- or to output both esmodules and commonjs versions. This could work, but I don't really like it, as it's forcing me to spend maintenance on the commonjs format, which is "the past", merely for this nuclear plugin pathway. (since my libraries are not used used by others atm)
Of the three options, option 2 is probably the one I'll end up going with, as it lets me keep the nuclear-vplugin pathway's fix restricted to the nuclear-vplugin repo itself. Also, it may come in handy for making the install process easier. (ie. users may not need to do "npm install" anymore, as long as I use only pure-javascript libraries)
But anyway, atm I'm doing the lazy approach (option 1): just avoiding those esmodule libraries for now.
Troubleshooting & Testing
We were getting a weird gradle error. So, the update was probably the source of the issue. I ran some troubleshooting stuff, which I think helped somewhat. However, probably the biggest problem was actually securely. It was blocking a download of a certain gradle file. Note to self, avoid on campus networks for compilation. Otherwise, we added functionality to the teleop program.
Created Text For URL [www.dailymaverick.co.za/article/2020-12-01-two-life-sentences-for-man-who-raped-and-beat-his-ex-girlfriend-to-death/]
A lot of shit was done.
MES Finallized and decorative objects placed. Blood system finalized with all gibs being put into the native gib queue option(Thx sgtmark for the idea.) Current v20b hellknights and barons will use red blood to differenciate during gameplay, primitive version of weapon switching system implemened. Texture BMAPs were added, weapon and monsters will be done once all added, marine skin idea abandoned for now until I sus out all the issues. PB footsteps were added, but I need to find out how to activate them, New v21 gold vehicles were added, the mod based off my testing seems to work with EDAY001 which is good, however the MAP01 imp troll is there. I beleive it is caused by the ACS Call to the PB 3.0 Spawner Script, so thanks mark for being a class ass like always. There are other changes that I probally forgot to mention because a lot was done. Next step provided no bugs with other stuff occur is the implementaion of weapons then monsters, and finishing the options menu since thats what people really care for lol.
Revert "Move rate_limiter out of Services module"
This reverts commit 8143521851bbe5de4eb2fe2ccd3b80f8d99693db.
We seem to have picked up an intermittent performance issue due to this change that we've not been able to diagnose.
We have seen the occasional SendEmailWorker take crazy amounts of time (around 4 hours). In trying to diagnose this on integration we found it relatively easy to have a pool of workers take > 10 mins to SendEmailWorker. We found that this 10 minutes was spent incrementing the RateLimiter. Reverting this commit resolved this problem.
I'm not sure where the time gets lost in this, certainly not for hours. I'm assuming there is some sort of deadlock that occurs which is resolved by a timeout. This look a total pain to debug and we don't have much time left as a team so I'm taking the rather ignorant route of reverting without understanding exactly why the problem occurs.
fuck you all shims
Signed-off-by: Gagan Malvi gagan@malvi.ml
pixmap: implement pixmaps as mirrors (not sheets)
-
move operators mentioned by the spec to decls.lisp
-
with-output-to-pixmap: don't change the sheet medium
The code that bound the sheet medium to a temporary medium associated with a pixmap had no purpose
- first of all sheet was not guaranteed to have an associated medium
- the macro's argument may be also a medium (that is not a sheet)
- the sheet is not specified to be accessed in a body, only the medium-var
-
remove unused protocols
-
with-pixmap-medium - macro is not used anymore (and operated under invalid assumption, that a pixmap is always a mediuM)
-
port-{de}allocate-pixmap is removed in favor of more specific operators {de}allocate-pixmap
-
remove a separate class hierarchy for pixmaps that implemented the sheet protocol
-
double buffering: remove a hacky logic
-
-
treat a pixmap as a mirror
Pixmaps are "off screen windows", and a mirror is a display window. This commit introduces a kludge, where medium-drawable may be directly set - that means in particular, that medium-drawable is not necessarily the sheet-mirror. This way we may implement with-output-to-pixmap without much hassle, however backend implementers should remember that they are working on medium drawables that are not necessarily their sheet mirrors, i.e
(xlib:draw-rectangle (medium-drawable medium) 1 1 2 2)
Instead of
(xlib:draw-rectangle (sheet-mirror (medium-sheet medium)) 1 1 2 2)
The latter looks awful enough, but some backends did that in the past.
-
refactor render backend class hierarchy
image-pixmap-mixin (and its subclasses) does not inherit from a sheet %make-image accepts width and height arguments instead of a "container" render medium-draw-* are more vary about medium region and transformation
Introducing functions MAYBE-TRANSFORMATION and MAYBE-REGION is an intermediate step before removing all medium access to sheets by correctly initializing its transformation during graft.
Revert "fuck you all shims"
This reverts commit eb67f8c1dbf64a75e6e283b87fbf86b2593fae90.
"4:55pm. Right now I am dwelling in my thoughts.
The next step here is really to just make use of the prepass. I have everything I need to put it into action. At this point I can also start thinking how to follow through with the results into the peval and codegen.
5pm. I could stop here for the day, but let me just do one more thing. Let me put this to use.
let build_file (s : SupervisorState) module_target =
match inputs s module_target with
| Ok x ->
let a,b = package.Run(x)
failwith "TODO"
| Error _ -> failwith "TODO"Let me start with this.
Where should I put the package stream? I am not sure. I'll leave this decision for later. If I can't decide, I'll just shunt it into the SupervisorState. It is not important right now.
Let me just sketch out this function. First thing's first - I need to take care of the error cases for the return of run.
let build_file (s : SupervisorState) module_target =
match inputs s module_target with
| Ok x ->
let a,b = package.Run(x)
match a with
| Some x -> // TODO: Don't forget the inner error.
failwith "TOOD"
| None -> failwith "TODO"
| Error _ -> failwith "TODO"I'll leave these as TODOs. What I really want to see is whether I am missing some inputs to the peval function.
let peval (env : TopEnv) (x : E) =type TopEnv = {
prototypes_instances : Dictionary<GlobalId * GlobalId, E>
nominals : Dictionary<GlobalId, Nominal>
}type Nominal = {|body : T; id : GlobalId; name : string|} ConsedNode // TODO: When doing incremental compilation, make the `body` field a weak reference.Let me take a short break here.
5:35pm. I am back.
type PrepassPackageEnv = {
prototypes_instances : Map<int, Map<GlobalId * GlobalId,E>>
nominals : Map<int, Map<GlobalId,{|body : T; name : string|}>>
term : Map<string,E>
ty : Map<string,T>
has_errors : bool
}Based on this, I can easily produce the inputs. Just turn it into a top env to merge all the package instances and then move from there.
...Let me turn off the router. I really want to call it a day, but let me do just one more thing.
let build_file (s : SupervisorState) module_target =
match inputs s module_target with
| Ok x ->
let a,b = package.Run(x)
match a with
| Some x ->
x >>- fun x ->
if x.has_errors then Error "There are type errors in at least one module."
else
failwith ""
| None -> Job.result (Error "Cannot find the target module.")
| Error x -> Job.result (Error x)Don't want to throw exceptions for this.
Now let me get the inputs. First let me get the main.
6:05pm. Done with lunch.
let build_file (s : SupervisorState) module_target =
match inputs s module_target with
| Ok x ->
let a,b = package.Run(x) // TODO: Take care of the stream.
match a with
| Some x ->
x >>- fun x ->
if x.has_errors then Error "There are type errors in at least one module."
else
match Map.tryFind "main" x.term with
| Some main ->
let top_env = package_to_top x
let prototypes_instances = Dictionary(top_env.prototypes_instances)
let nominals =
let t = HashConsing.HashConsTable()
let d = Dictionary()
top_env.nominals |> Map.iter (fun k v -> d.Add(k, t.Add {|v with id=k|}))
d
Ok(PartEval.Main.peval {prototypes_instances=prototypes_instances; nominals=nominals} main)
| None -> Error <| sprintf "Cannot find the main function in module. Path: %s" module_target
| None -> Job.result (Error <| sprintf "Cannot find the target module. Path: %s" module_target)
| Error x -> Job.result (Error x)I'll close the day with this. This actually typechecks.
Tomorrow, I will follow through with this into codegen and deal with that package stream. Then once I have that, I'll actually be able to compile Spiral code. That would be impressive wouldn't it?
Once I get to that point I'll be able to start testing.
Right now, the typechecker and the prepass are in very good shape as far as their efficiency and composability are concerned.
I did an A grade job there. The build file and partial evaluation that is tied to it do have a lot of optimization work left for them. But as per plan I will leave that for future versions of Spiral that have a lot of code needing to be compiled for them.
For the prepass I could just reuse the typechecking machinery, but peval will require new things.
It is far more important that I test everything out produce some quality libraries first. Optimizing peval will be tough, but I'll be able to do it if I can allocate a few week to it."
add tears, frustration, deep breathing, a good night's sleep, help from a friend, and a bug fix.
I hate my life. Stop changing your name Marco. Please stop this
Update LetterMappings.cs
Checked that a bunch of symbols were present; added comments so that I can find them again when I forget they're there.
Missing: Key.OEMsomethingsomething, the @' (at symbol/apostrophe) key - I don't know what it's called. Help pls!
Added:
- V: ✅ as I use V for checkmarks
- X: ❌, moved '×' (multiply) to 2nd
- Moved bullet point ● from Key.OemComma to Key.Subtract (I usually use this key for bullet points)
- Moved ellipsis (triple dot) character from Key.OEMComma (what on earth was it doing there?) to Key.OemPeriod
- Key.OemTilde: duplicated ñ, ã, õ
- Missing
Key.OemOpenBrackets(sad smiley, likeKey.D9) - Missing
Key.D6( dagger/doubledagger † ‡, reference symbol ※) - Missing
Key.D7(some of my favorite emojis) and experimental Arabic "ﷺ" (sallallahu alaihi wasallam / Peace and blessings be upon him). Shifted, it's different emojis - Missing Portuguese accents to A, O (ã, â, ô, õ, ó)
- Experimental: Hebrew alphabet to end of respective keys (for Heb. letters that have multiple Latin equivalents: Gimel=G, Waw/Vav=W, Chet/Heth and He=H, Tet and Taw=T, Yod=J, Koph=K, Samech, Shin, Tsade=S, ( (WTF, whenever I paste a 2nd Hebrew char, it swaps the direction of my cursor?!). "Final" forms of letters are the shift/caps version. Diacritics and special letters omitted because I don't know Hebrew and can't be bothered to tinker further with my keyboard direction swapping. If they prove annoying, I'll remove Hebrew in favour of Hebrew letters as symbols, e.g. U+2135 and up (ℵℶℷℸ)
- O: Added oethel (œ , Œ ), rearranged so that hôpital (Fr.) comes first, oethel 2nd (The Queen's British English uses it everywhere; it's only fallen out of use because bloody keyboards don't have it)
- duplicated ÷ to
[forward slash/question mark key]and5/%(not every keyboard has a Numpad divide key) [question mark/forward slash]: Interrobang ‽- P: Paragraph marker ⁋
[4/currency]: ¢ cent- F: Phi Φ φ
[8/asterisk]: more asterisks ⁑ ⁂- D: degrees symbol º
- P: Psi ψ Ψ (pressure)
Reference: https://unicode-table.com/en/ https://en.wikipedia.org/wiki/List_of_Unicode_characters https://en.wikipedia.org/wiki/Hebrew_alphabet
Merge pull request #3 from VernalEquinox000/NewsFeedEnis
FUCK YOU GIT HUB
Created Text For URL [sundiatapost.com/burna-boy-accused-by-23-year-old-girl-of-cheating-on-her-with-stefflon-don/]