3,099,443 events, 1,146,636 push events, 1,828,446 commit messages, 149,082,498 characters
Merge #984 #987 #988 #989
984: Added Takeaway r=poteto a=fedorbeets
- I have read the contributing guidelines
- I agree to the Code of Conduct
- I have followed the format prescribed in the contributing guidelines
- (OPTIONAL) In your pull request message, add additional context on the interview process if necessary
987: Removes Ableton r=poteto a=brahyam
Removing ableton from the list as a close friend of mine recently had an interview for an iOS position and during the call it was required for him to perform some classic whiteboard challenges trying to produce ascii art. They call it a pair programming session. There was no take home challenge and the discussion was not about some real life problem that their facing in Ableton (unless they are generating ascii art on iOS all day long for their products?????).
If there is any doubt I can provide the whiteboard challenge files that they send during the interview on request.
Thanks
PS. My friend would like to remain anonymous
- I have read the contributing guidelines
- I agree to the Code of Conduct
- I have followed the format prescribed in the contributing guidelines
- (OPTIONAL) In your pull request message, add additional context on the interview process if necessary
988: Add AImotive to the list r=poteto a=Lehoczky
- I have read the contributing guidelines
- I agree to the Code of Conduct
- I have followed the format prescribed in the contributing guidelines
- (OPTIONAL) In your pull request message, add additional context on the interview process if necessary
989: Add Angaza r=poteto a=chadnorvell
- I have read the contributing guidelines
- I agree to the Code of Conduct
- I have followed the format prescribed in the contributing guidelines
- (OPTIONAL) In your pull request message, add additional context on the interview process if necessary
- A blog article outlining our interview process
- Angaza's engineering culture on Key Values
Co-authored-by: Fedor Beets [email protected] Co-authored-by: brahyam [email protected] Co-authored-by: Lehoczky Zoltán [email protected] Co-authored-by: Chad Norvell [email protected]
i hate my life
yup. It dosent work but its the right idea!
Fix: object materials: many bugs and omissions for material hatred
This started out with me trying to add a special case to searmsg(), which then turned into making the searmsg() code xhity-compatible, i.e. working regardless of who the defender and aggressor are (or even having no aggressor), and ballooned into fixing a ton of things that did not work correctly with regards to the material hatred system.
Changes to functions:
- searmsg now takes a fourth argument, a boolean representing that the message should be minimal; e.g. "The silver sears foo's flesh!" or "foo is seared!" instead of "Your silver longsword sears foo's flesh!"
- searmsg now uses "recoil" rather than "flinch" because it makes for slightly better and less verbose sentence structure.
- New function, attack_contact_slots, which determines based on a monster attack what gear slots if any should be counted as the defender hating it. For instance, attack_contact_slots of an AT_CLAW attack will return the glove and ring slots.
- mon_hates_material now correctly determines that a player infected with lycanthropy but not transformed should hate silver.
- All the functions above are now xhity-compatible.
Bugs fixed:
- Hate_material didn't detect a vampshifted player (one who has #monster'd into fog or wolf or bat form but can #monster again to resume vampire form). Now, Hate_material is just a shorthand for mon_hates_material, which didn't previously include a case for a non-transformed player with lycanthropy.
- Monster hitting player with a weapon in melee combat applied material damage twice.
- Player hitting monster with a weapon in melee combat applied material damage twice.
- hates_material() didn't test is_elf() for iron hatred, meaning that it didn't apply to elvish monsters that are not S_ELF.
Omitted cases that should have caused material damage but didn't:
- Player hitting self in the foot with a pick
- Monster versus monster direct contact in melee combat
- Player kicking an object barefoot
- Player kicking an iron door barefoot
- Monster wearing a helm and headbutting player
Omitted cases that did cause damage but lacked a message:
- Player throwing something up and hitting themself in the head with it
- Monster hitting a monster with a weapon in melee combat
- Monster hit by an object from a trap
- Player hitting a monster with an iron ball or iron chain
- Player crashing into iron bars
- Player with boots kicking a monster, while polyselfed into a form with kick attacks
Other:
- I tried to add a comment everywhere a material hatred if statement does NOT add additional damage due to dmgval() having already added it. Anywhere one of these if statements doesn't have either a damage increase or a comment stating it happened elsewhere is considered a bug.
- Unified codepaths for monster touching player with a body made of a material player hates and monster hitting player while wearing gear made of a material player hates.
- Many of the hmonas() calls for special_dmgval have been merged. The code here for multiple claw/touch attacks hitting with strictly alternating arms has been removed; the player will hit with whatever gives the highest damage.
- Iron haters opening and closing an iron door barehanded is a case I considered for applying material damage, but decided not to because it would really just be annoying. It can be assumed they all have glass doorknobs or something.
One case that this does NOT supply at this time is the one in which the aggressor hits a defender made of a material they hate with their bare skin, and should take damage. I can't think of a way to do this right now that doesn't involve adding more global variables (that could handle the case in the passive() functions). For the time being it shouldn't matter much; it would matter more if monks could be elves or similar.
Update from Forestry.io Other People updated _drafts/2020-06-29-midnight-crawler.md Other People deleted _posts/2020-06-29-midnight-crawler.md Other People updated _drafts/2020-04-06-i-left-my-heart-in-amsterdam.md Other People deleted _posts/2020-04-06-i-left-my-heart-in-amsterdam.md Other People updated _drafts/2020-04-24-golden-boy.md Other People deleted _posts/2020-04-24-golden-boy.md Other People updated _drafts/2020-04-01-girls-of-the-limberlost.md Other People deleted _posts/2020-04-01-girls-of-the-limberlost.md
Update 2020-new-outline.md
I updated some very small sections of the document just so that what we discussed in today's meeting (#16) would be reflected here. These are the things I modified:
- Removed the initial group project text as it was redundant with the new "collaborative troubleshooting" evaluation section (named this tentatively)
- Updated the mini-project section but kept it minimal since I will be creating an individual document for this (as discussed in #16)
- Added brief points discussed in #16 and today's meeting to "participation" section
- Commented on a few points that I had made notes for but forgot to bring up in the meeting today: (a) in the "office hours" section, added a few suggestions; (b) added a few notes about the website in the "to develop" section; (c) opened up a point for discussion also under "to develop" regarding what we discussed a couple weeks ago about helping students navigate Zoom.
I look forward to hearing your thoughts! Thank you.
Strong Password
Louise joined a social networking site to stay in touch with her friends. The signup page required her to input a name and a password. However, the password must be strong. The website considers a password to be strong if it satisfies the following criteria:
Its length is at least 6 . It contains at least one digit. It contains at least one lowercase English character. It contains at least one uppercase English character. It contains at least one special character. The special characters are: !@#$%^&*()-+ She typed a random string of length n in the password field but wasn't sure if it was strong. Given the string she typed, can you find the minimum number of characters she must add to make her password strong?
Note: Here's the set of types of characters in a form you can paste in your solution:
numbers = "0123456789" lower_case = "abcdefghijklmnopqrstuvwxyz" upper_case = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" special_characters = "!@#$%^&*()-+"
https://www.hackerrank.com/challenges/strong-password/problem
"9:30am. I am up. Let me chill a bit and I will start.
10:10am. Time to start.
type Bundle = (int * TopStatement) [] // offset * statement
let block_bundle (l : Block list) : Bundle [] * VSCError [] =Let me make bundle a type.
10:15am. Ok, let me open a new file. It is time for Typechecking.fs to make its debut. It will operator on those bundle arrays.
For the time being, I won't bother thinking exactly how to fit it exactly into blockization.
10:20am. Ah yeah...
I remembered a plan I had made during the night. Thanks to the work I did yesterday, the top-down and bottom-up phase are nicely delineated in the parser. In its current form Spiral's parser is trully complete, it is not the same situtation as back in January when I only had the barest needed to run it.
10:25am. What I am talking about is parsing of the default ints and floats. In the top-down segment I intend to make them return polymorphic, I'll have the typechecker annotate them with the specific type and leave the partial evaluator to parse them as literals, but for bottom up defaults, I should do something else. I should parse them as i32 and f64 right away.
But rather than hardcoding the defaults, I am thinking of adding a pragma at the top level.
#pragma default i32
#pragma default f64
This seems good. I won't make pragma a keyword.
10:30am. Ok, let me busy myself with this for a bit.
type Env = {
tokens : (Range * SpiralToken) []
comments : Tokenize.LineComment option []
i : int ref
is_top_down : bool
default_int : PrimitiveType
default_float : PrimitiveType
}Now let me make use of this in the number parser.
...Ah, no wait. Shit. If I pragmas directly in the file itself, I won't be able to independent parsing of blocks.
So pragmas are out.
Setting these kinds of defaults seems more like a job for the project file. I'll do it there then.
let pat_value =
(read_value |>> PatValue)
<|> (fun d ->
if d.is_top_down then (read_default_value |>> PatDefaultValue) d
else (read_default_value >>= fun (r,x) _ ->
) d
)First I have to do it in pattern. But I really should factor out the number parser for this.
Did I have that in the tokenizer?
let number (s: Tokenizer) =
let from = s.from
let ok x = ({from=from; nearTo=s.from}, x) |> Ok
let parser (s: Tokenizer) =
if peek s = '-' && Char.IsDigit (peek' s 1) && is_prefix_separator_char (peek' s -1) then
inc s
number_fractional s |> Result.map (function
| (a,Some b) -> sprintf "-%s.%s" a b
| (a,None) -> "-"+a)
else number_fractional s |> Result.map (function
| (a,Some b) -> sprintf "%s.%s" a b
| (a,None) -> a)
let followedBySuffix x (s: Tokenizer) =
let inline safe_parse string_to_val val_to_lit val_dsc =
if is_separator_char (peek s) then
match string_to_val x with
| true, x -> val_to_lit x |> TokValue |> ok
| false, _ -> Error [{from=from; nearTo=s.from}, (sprintf "The string %s cannot be safely parsed as %s." x val_dsc)]
else error_char s.from "separator"
let skip c = skip c s (fun () -> true) (fun () -> false)
if skip 'i' then
if skip '8' then safe_parse SByte.TryParse LitInt8 "int8"
elif skip '1' && skip '6' then safe_parse Int16.TryParse LitInt16 "int16"
elif skip '3' && skip '2' then safe_parse Int32.TryParse LitInt32 "int32"
elif skip '6' && skip '4' then safe_parse Int64.TryParse LitInt64 "int64"
else error_char s.from "8,16,32 or 64"
elif skip 'u' then
if skip '8' then safe_parse Byte.TryParse LitUInt8 "uint8"
elif skip '1' && skip '6' then safe_parse UInt16.TryParse LitUInt16 "uint16"
elif skip '3' && skip '2' then safe_parse UInt32.TryParse LitUInt32 "uint32"
elif skip '6' && skip '4' then safe_parse UInt64.TryParse LitUInt64 "uint64"
else error_char s.from "8,16,32 or 64"
elif skip 'f' then
if skip '3' && skip '2' then safe_parse Single.TryParse LitFloat32 "float32"
elif skip '6' && skip '4' then safe_parse Double.TryParse LitFloat64 "float64"
else error_char s.from "32 or 64"
else TokDefaultValue x |> ok
(parser >>= followedBySuffix .>> spaces) sYeah, it is in the tokenizer.
10:45am.
let inline safe_parse string_to_val val_to_lit val_dsc (r,x) =
match string_to_val x with
| true, x -> Ok(val_to_lit x)
| false, _ -> Error [r, sprintf "The string %s cannot be safely parsed as %s." x val_dsc]Actually since in all cases I am doing the parsing to the literal, I can implement this as a separate function.
10:45am. Oh yeah, this means I am going to have to redo the entire project now that the project files can affect more than just the compilation order. But this works for me. It is actually less work to do it this way.
10:55am.
let bottom_up_number (r : Range,x : string) (d : Env) =
let inline f string_to_val val_to_lit val_dsc =
match string_to_val x with
| true, x -> Ok(val_to_lit x)
| false, _ -> Error [r, sprintf "The string %s cannot be safely parsed as %s." x val_dsc]
if x.Contains '.' then
match d.default_float with
| Float32T -> f Single.TryParse LitFloat32 "f32"
| Float64T -> f Double.TryParse LitFloat64 "f64"
| x -> failwith "Compiler error: Invalid default float type. Got: %A" x
else
match d.default_int with
| Int8T -> f SByte.TryParse LitInt8 "i8"
| Int16T -> f Int16.TryParse LitInt16 "i16"
| Int32T -> f Int32.TryParse LitInt32 "i32"
| Int64T -> f Int64.TryParse LitInt64 "i64"
| UInt8T -> f Byte.TryParse LitUInt8 "u8"
| UInt16T -> f UInt16.TryParse LitUInt16 "u16"
| UInt32T -> f UInt32.TryParse LitUInt32 "u32"
| UInt64T -> f UInt64.TryParse LitUInt64 "u64"
| x -> failwith "Compiler error: Invalid default int type. Got: %A" xFor the time being I'll just set some sensible defaults. I won't get back to the config parser until much later.
Let me plug this in everywhere.
10:55am. Ah, right. I need a specific ParserError for this.
11:05am.
let pat_value =
(read_value |>> PatValue)
<|> (fun d ->
if d.is_top_down then (read_default_value |>> PatDefaultValue) d
else (read_default_value >>= bottom_up_number |>> PatValue) d
)Now let me abstract this a bit.
let inline read_default_value on_top on_bot d =
try_current d <| function
| p, TokDefaultValue t' ->
skip d
if d.is_top_down then Ok(on_top (p,t'))
else bottom_up_number (p,t') d |> Result.map on_bot
| p, _ -> Error [p, ExpectedLit]Now let me plug this in everywhere.
let pat_value = (read_value |>> PatValue) <|> (read_default_value PatDefaultValue PatValue)This typechecks.
This is why I use F# as my language of choice. Partial application of function arguments is just so powerful.
let case_default_value = read_default_value RawDefaultLit RawLitAnd here. But shouldn't there...
Ah, no it should not. I do not have numbers in root_type.
11:20am. I am thinking...
Actually, I avoid having to redo the whole project if I just set defaults to be valid across all the project files. Then I'd only need to redo the project if they change.
Let me go with that. That will be the least amount of work.
Let me just set the sensible default for now.
let env : BlockParsing.Env =
{comments = comments; tokens = Array.concat tokens; i = ref 0;
is_top_down = is_spi; default_int=Int32T; default_float=Float64T}Oh yeah, that reminds me. Have I set ; to be optional in the term record parser?
let record_create = range (sepBy record_create_body (skip_op ";")) |>> fun (r,withs) -> (r,[],withs,[])Nope.
let record_create = range (sepBy record_create_body (optional (skip_op ";"))) |>> fun (r,withs) -> (r,[],withs,[])((skip_keyword SpecWith >>. sepBy record_with_bodies (optional (skip_op ";"))) <|>% [])Ok, that should take care of that.
Spiral's parser is quite a beast now.
11:25am. Let me try this out.
Yeah, it works. Let me try out the record as well
Unhandled exception: System.Exception: Compiler error: The parser passed into `range` has to consume at least one token for it to work.It says this is in record create.
let record_create_body = range record_var .>>. record_body |>> RawRecordWithSymbol
let record_create = range (sepBy record_create_body (optional (skip_op ";"))) |>> fun (r,withs) -> (r,[],withs,[])This is a really strange error.
...It happens as soon as I open {}. First of all, is this error related to me putting in those optionals, or is it something else.
Server bound to: tcp://*:13805
Unhandled exception: System.Exception: Compiler error: The parser passed into `range` has to consume at least one token for it to work.
at Spiral.BlockParsing.record_create@878-8.Invoke(FSharpList`1 x) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language v0.2 (typechecking)\BlockParsing.fs:line 878
at Microsoft.FSharp.Core.ResultModule.Map[T,TResult,TError](FSharpFunc`2 mapping, FSharpResult`2 result) in F:\workspace\_work\1\s\src\fsharp\FSharp.Core\result.fs:line 9
at Spiral.BlockParsing.record_create@878-7.Invoke(Env s) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language v0.2 (typechecking)\BlockParsing.fs:line 878
at Spiral.BlockParsing.record_create@878-10.Invoke(Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language v0.2 (typechecking)\BlockParsing.fs:line 878
at Spiral.BlockParsing.curlies@432-1.Invoke(Env d) in C:\Users\Marko\Source\Repos\The Spiral Language\The Spiral Language v0.2 (typechecking)\BlockParsing.fs:line 432Hmmm, ok. It is not related to optionals. Rather the issue is that empty records are valid in Spiral.
11:35am.
let record_create = range (curlies (sepBy record_create_body (optional (skip_op ";")))) |>> fun (r,withs) -> (r,[],withs,[])Ok, I folded the curlies inside. This should work.
Let me give it a try.
inl r = {q with a=1; b=2
c=3}
This works. Great.
I get an error when I try a too large of an int. It is no problem.
11:45am. What is next? The Typechecking.fs debut. Let me do it.
11:50am.
module Spiral.TypecheckingI am finally here. It took too long.
12pm. I am thinking how I should start this. I'll do that by considering just the case of non-recursive top level statements and moving from there.
12:05pm. Hmmm...in the typechecker, I am going to have to erase the distinction between nominal and union types. I'll just call them HigherOrder types and be done with it. Whether they are union or nominal I'll check just inside the patterns based on the first argument.
12:10pm. Let me just take that break here since I am already getting distracted.
In constrast to the prepass and the partial evaluator, the typechecker is something I barely have experience of. Maybe it really will take me a full month.
If I were experienced, I think it would be doable in a week, but right now who knows."
"1pm. Done with breakfast, but I am starting to hear some thunder in the distance. The sky is bright and sunny so I doubt this will be anything serious.
1:35pm. Done with chores. Let me see if I can if I can straighten my mind and home into the next part.
1:40pm. Focus me, focus.
type TopStatement =
| TopAnd of Range * TopStatement
| TopInl of Range * VarString * RawExpr * is_top_down: bool
| TopRecInl of Range * VarString * RawExpr * is_top_down: bool
| TopUnion of Range * TypeVar list * RawTExpr list
| TopNominal of Range * TypeVar list * RawTExpr
| TopPrototype of Range * VarString * VarString * TypeVar list * RawTExpr
| TopType of Range * VarString * TypeVar list * RawTExpr
| TopInstance of Range * VarString * VarString * TypeVar list * RawExprNow what do I do about this? Let me just make a function to typecheck a RawExpr.
I won't care about generalizing the top level statements.
inl f x =
inl (+) (a : i32) (b : i32) = !!!!Add(a,b) : i32
1+2+3+x
How about I start with something easy like this?
Before you can attain any kind of skill, you first need a target. If you do not have targets, the learning will be haphazard.
1:55pm. Focus me, stop reading the ML sub on the side.
2:20pm. I've come up with a plan.
2:40pm. I am elaborating it in my head. Though I gave that simplistic example, I still have to think ahead. Yeah, one thing I have to decide before I start is how will I deal with unifying kinds. The answer is to come up with metavariables for kinds as well.
At first glance this seems hard, but now that I am going through it, I see that it will be no trouble at all. Quite remarkable.
Also, I thought that it might be necessary to transform the parsed AST to the typed one, but I think a better way to go would be to just use a separate dictionary and annotate all the variables and the default values based on their ranges.
That will be amazing as I'll be able to hook that up into editor support as well.
2:50pm. Hmmm, I see. When it comes to metavariables I can just use a single global resizable array rather than a dictionary. Metavariables always point to either other metavars or principal types.
2:55pm. I am having deja vu.
I got the idea what when I am unifing two metavaraibles, I should make it so that that the later one points to the earlier one.
The reason why is that this will make it a lot easier to do let generalization.
inl a q w =
...
inl b r t = =
...
inl c y u = ...
Every let statement follow be a function is a let generalization node.
Even if I have a single global array for metavariables, on every node I can save the present level, evaluate the body and the pop all the additions down to the present level. Those additions that are None are the metavars I need to let-generalize. The same goes for kind metavars.
3:05pm. Ok, the scheme I have in mind would work for quite a lot of things.
I think mostly everything checks out. Except mutually recursive functions.
I need to think.
Could I just type infer those similarly to nested statements?
3:15pm. Let me step away from the screen for a bit. I have to grind this problem in my mind for a while and am tired of sitting here."
Keep calm and carry on
| Birthday | Favorite color | Favorite food | Pinneapple on pizza |
|---|---|---|---|
| 08/11 | purple | veggies | No |
- gardening
- painting
- studying on EDX
- circular economy
- smart grids
###You can always count on me when you need moral support
I will help my teammates learn by teaching.
I will contribute by maintaining a good team spirit.
When I finished school I was not sure what to do with my life. I was inclined to study IT at a technical institute, but my teacher persuaded me to go to shipping university. I also tried to get into art school but failed the exam. 10 years later I am living in Antwerp, making a career switch. I am studying web development full time at BeCode, as well as painting part-time at the Royal Academy of Fine Arts.
It's never too late to start over
Searching for my purpose
[<< previous][previous]:https://github.com/Tessakam/markdown-challenge || VICTORIA || [next >>][next]:https://github.com/whitneyz/markdown-challenge
A Bunch of Code Refactoring because I'm an idiot + a cooler homepage
Summary:
First, I think this is first slightly presentable version of the project. It still sucks but its a start.
Changes:
- Made every every classname unique to each component (yikes)
- Due to 1, I had to make some CSS changes to keep it consistent.
- Added a new homepage that emulates Windows 98. Why? Because I can do what I want.
TODO (Mainly stop procrastinating on the timeline):
- Work on all the pages to be browser consistent. I'm not sure whats going on but Chrome and Safari are slightly off for some of this. I've already fixed a brief webkit issue but will need to troubleshoot more
- Timeline stuff: TODO: fix the image aligment in UI TODO: Figure out to make timelines go to left and right TODO: Add logic for clicking on events
- Once thats all done, which will take a long time, I plan on working on a mobile version. From my brief testing, it'll require a good amount of testing. The newest versions of the iPad look good though!
"4:25pm. ...It is good. I think I just about understand everything at this point. I know how to do recursive functions. I even know how F# does that trick with unbound type vars.
4:30pm. Let me take a short break from all this intense thinking.
4:50pm. Let me resume.
Ok, doing everything that I have in mind is a lot of work - but for the first time everything I want to do is within my reach. There are no longer any mysteries to me how exactly typechecking should be done. I am done in theory, but not in practice. All I have to do is walk to the finish line and collect my prize - Spiral v0.2.
I can do this.
I am not sure I feel like starting anything new for the day right now.
Instead of working on the typechecker, let me do a little in the config parser. I'll add the defaultInt and defaultFloat fields.
5:05pm.
type PrimitiveType =
| UInt8T
| UInt16T
| UInt32T
| UInt64T
| Int8T
| Int16T
| Int32T
| Int64T
| Float32T
| Float64T
| BoolT
| StringT
| CharT
let default_int =
[ "i8", Int8T; "i16", Int16T; "i32", Int32T; "i64", Int64T; "u8", UInt8T; "u16", UInt16T; "u32", UInt32T; "u64", UInt64T ]
|> List.map (fun (a,b) -> pstring a >>% b) |> choice
let default_float = [ "f32", Float32T; "f64", Float64T ] |> List.map (fun (a,b) -> pstring a >>% b) |> choice
type Schema = {
dirSource : string
dirOut : string
name : string
version : string
files : string []
defaultInt : PrimitiveType
defaultFloat : PrimitiveType
}Plugged this in.
Great.
I'll make use of this to great effect later on.
5:10pm. With this I have everything I need in the config parser.
5:15pm. I know I said would that simple example, but forget that. A little bit of forethought saves a whole lot of work.
type TopStatement =
| TopAnd of Range * TopStatement
| TopInl of Range * VarString * RawExpr * is_top_down: bool
| TopRecInl of Range * VarString * RawExpr * is_top_down: bool
| TopUnion of Range * TypeVar list * RawTExpr list
| TopNominal of Range * TypeVar list * RawTExpr
| TopPrototype of Range * VarString * VarString * TypeVar list * RawTExpr
| TopType of Range * VarString * TypeVar list * RawTExpr
| TopInstance of Range * VarString * VarString * TypeVar list * RawExpr5:20pm. Stop reading /pol/ threads me. Before I can start I need to decide on one thing...
Union and nominal types - how will I represent them?
6:05pm. I've been in thought all this time.
I see it. I know how to do it.
I'll just use a nominal id with its associated kind annotation. Nominal ids will have staged reduction, while regular type functions will get reduced. This won't be hard at all.
I can see it vividly now.
6:10pm. After today's session I have really quite a lot of ammo to fire in my mind.
The only thing I haven't thought about it how to do multiple errors in the typechecker. I think for my initial run I'll just halt on the first error.
That is the easiest way to go. Resumable errors will have lot of shared structure with the rest so I can just focus on dealing with the simpler version first without fear of losing much.
None of this is particularly complex. It is differnt, but it won't take me longer than the parser. So I should be done in two weeks if I start turning the crank tomorrow.
I'll start with type definitions and move my way from there.
6:15pm. The issue I had today is that even though I could have started off with simple expressions, the first thing waiting for me are patterns. So unless I plan ahead, I won't be able to get far anyway.
Damn, this typechecker is finally within my reach. I have the refined design. You can be I won't be slacking off for the next two weeks.
The future is waiting for me. I still haven't found my power. I need to keep up the search.
6:20pm. I need to go from 1k games using a single net to 1M games using an ensemble of them. I need to go forward.
In 2018 I did not get far, but in my next attempt I will have both much better language and much better hardware. Maybe this 'work' thing will get me somewhere in the end.
I am the one who wants to see myself win in the end most of all. Just what kind of power will be the completed Spiral language and the next wave of hardware allow me to posses?"
Update README.md
Acted too quickly. Some feel that there might be some level of value with the content of this repo, so I'm reverting it back to where it was.
My personal thoughts are to abandon it, and eventually remove it as it has very low level of valuable content on it, it's quite repetitive, and basically shows my journey down the rabbit-hole that is Child Key Derivation. I have learned so much in the last week as opposed to all the work and funds I put into it.
Frankly, the new repo is more apropos to the original project idea, has a simpler and more inclusive name, actually solves the problem in a simple and effective manner, and provides a higher level of value than this one.
IOW, I'm ready to scrap this effort in favor of the new effort, which is actually solving the problem that this repo was supposed to do. Not to say that this repo is junk, just that it was a great staging area and learning experience, hopefully for all involved.
I welcome feedback to my opinions.
Bob
Fuck jannies fuck github but most importantly fuck you (#145)
Co-authored-by: GoonBad [email protected]
[java-source-utils] Add Java source code utilities
Context: https://github.com/javaparser/javaparser/tree/javaparser-parent-3.16.1 Context: dotnet/java-interop#623
There are two parts of the current .jar binding toolchain which are
painful and could be improved:
- Parameter names
- Documentation extraction
Parameter names (1) are important because they become the names of event members as part of "event-ification". As such they are semantically important, and the default behavior of "p0" makes for a terrible user experience.
If the .class files in the .jar file are built with
javac -parameters (4273e5ce), then the .class file will contain
parameter names and we're good. However, this may not be the case.
If the .class files are built with javac -g, then we'll try to
deduce parameter names from debug info, but that's also problematic.
What else can be used to provide parameter names?
It is not unusual for Java libraries to provide "source .jar" files,
e.g. Android provides android-stubs-src.jar files, and other
libraries may provide a *-sources.jar file. The contents of these
files are Java source code. These files are used by Android IDEs to
provide documentation for the Java library. They contain classes,
methods, parameter names, and associated Javadoc documentation.
What they are not guaranteed to do is compile. As such, we can't
compile them ourselves with javac -parameters and then process the
.class files, as they may refer to unresolvable types.
"Interestingly", we already have some tooling to deal with this:
tools/param-name-importer uses a custom Irony grammar to parse
the Android SDK *-stubs-src.jar files to grab parameter names.
However, this tooling is too strict; try to pass arbitrary Java
source code at it, and it quickly fails.
Which brings us to documentation (2): we have a javadoc2mdoc tool which will parse Javadoc HTML documentation and convert it into mdoc(5) documentation, which can be later turned into XML documentation comments files by way of mdoc export-msxdoc(1), but this tool is (1) painful to maintain, because it processes Javadoc HTML, and (2) requires Javadoc HTML.
Google hasn't updated their downloadable Javadoc .zip file since
API-24 (2016-October). API-30 is currently stable.
If we want newer docs, we either need to scrape the
developer.android.com/reference website to use with the existing
tooling, or... we need to be able to read the Javadoc comments within
the *-stubs-src.jar files provided with the Android SDK.
(Note: Android SDK docs are Apache 2; file format conversion is fine.)
We thus have two use-cases for which parsing Java source code would be useful..
As luck would have it, there's a decent Apache 2-licensed Java project which supports parsing Java source code: JavaParser.
Add a new tools/java-source-utils program which will parse Java
source code to produce two artifacts: parameter names and
consolidated Javadoc documentation:
$ java -jar java-source-utils.jar --help
java-source-utils [-v] [<-a|--aar> AAR]* [<-j|--jar> JAR]* [<-s|--source> DIRS]*
[--bootclasspath CLASSPATH]
[<-P|--output-params> OUT.params.txt] [<-D|--output-javadoc> OUT.xml] FILES
Provide --output-params OUT.params.txt, and the specified file will
be created which follows the file format laid out in
JavaParameterNamesLoader.cs:
package java.lang
;---------------------------------------
class Object
wait(long timeout)
Provide --output-javadocs OUT.xml, and the resulting file will be a
class-parse-like XML file which uses //@jni-signature as the "key"
and a child <javadoc/> element to contain documentation, e.g.:
<api api-source="java-source-utils">
<package name="java.lang">
<class name="Object" jni-signature="Ljava/lang/Object;">
<javadoc>…</javadoc>
<constructor jni-signature="()V">
<javadoc>…</javadoc>
</constructor>
<method name="wait" jni-signature="(J)V" jni-returns="V" returns="void">
<parameter name="name" jni-type="J" type="long" />
<javadoc>…</javadoc>
</method>
</class>
</package
</api>
This should make it possible to update the Xamarin.Android API documentation without resorting to web scraping (and updating the code to deal with whatever new HTML dialects are now used).
If neither --output-params nor --output-javadocs is used, then
--output-javadocs will be executed, writing to stdout.
The XML file also contains parameter name information, so that one file can be the "source of truth" for parameter names and documentation.
FILES can be:
- Java source code in a
.javafile; or - A file with a
.jaror.zipextension, which will be extracted into a temp directory and all.javafiles within the directory will be processed; or - A directory tree, and all
.javafiles will be processed.
If a single file references other types, the "root" directory containing
those types may need to be specified via --source DIR:
$ java -jar "bin/Debug/java-source-utils.jar" -v \
-s $HOMEandroid-toolchain/sdk/platforms/_t \
$HOME/android-toolchain/sdk/platforms/_t/android/app/Activity.java \
-P android.params.txt -D android.xml >o.txt 2>&1
TODO:
In some scenarios, types won't be resolvable. What should output be?
We don't want to require that everything be resolvable -- it's painful, and possibly impossible, e.g. w/ internal types -- so instead we should "demark" the unresolvable types.
.params.txt output will use .* as a type prefix, e.g.
method(.*UnresolvableType foo, int bar);
docs.xml will output L.*UnresolvableType;.
Fix JavaParameterNamesLoader.cs to support the above.
[java-source-utils] Add Java source code utilities (#623)
Context: https://github.com/javaparser/javaparser/tree/javaparser-parent-3.16.1 Context: dotnet/java-interop#623
There are two parts of the current .jar binding toolchain which are
painful and could be improved:
- Parameter names
- Documentation extraction
Parameter names (1) are important because they become the names of event members as part of "event-ification". As such they are semantically important, and the default behavior of "p0" makes for a terrible user experience.
If the .class files in the .jar file are built with
javac -parameters (4273e5ce), then the .class file will contain
parameter names and we're good. However, this may not be the case.
If the .class files are built with javac -g, then we'll try to
deduce parameter names from debug info, but that's also problematic.
What else can be used to provide parameter names?
It is not unusual for Java libraries to provide "source .jar" files,
e.g. Android provides android-stubs-src.jar files, and other
libraries may provide a *-sources.jar file. The contents of these
files are Java source code. These files are used by Android IDEs to
provide documentation for the Java library. They contain classes,
methods, parameter names, and associated Javadoc documentation.
What they are not guaranteed to do is compile. As such, we can't
compile them ourselves with javac -parameters and then process the
.class files, as they may refer to unresolvable types.
"Interestingly", we already have some tooling to deal with this:
tools/param-name-importer uses a custom Irony grammar to parse
the Android SDK *-stubs-src.jar files to grab parameter names.
However, this tooling is too strict; try to pass arbitrary Java
source code at it, and it quickly fails.
Which brings us to documentation (2): we have a javadoc2mdoc tool which will parse Javadoc HTML documentation and convert it into mdoc(5) documentation, which can be later turned into XML documentation comments files by way of mdoc export-msxdoc(1), but this tool is (1) painful to maintain, because it processes Javadoc HTML, and (2) requires Javadoc HTML.
Google hasn't updated their downloadable Javadoc .zip file since
API-24 (2016-October). API-30 is currently stable.
If we want newer docs, we either need to scrape the
developer.android.com/reference website to use with the existing
tooling, or... we need to be able to read the Javadoc comments within
the *-stubs-src.jar files provided with the Android SDK.
(Note: Android SDK docs are Apache 2; file format conversion is fine.)
We thus have two use-cases for which parsing Java source code would be useful.
As luck would have it, there's a decent Apache 2-licensed Java project which supports parsing Java source code: JavaParser.
Add a new tools/java-source-utils program which will parse Java
source code to produce two artifacts: parameter names and
consolidated Javadoc documentation:
$ java -jar java-source-utils.jar --help
java-source-utils [-v] [<-a|--aar> AAR]* [<-j|--jar> JAR]* [<-s|--source> DIRS]*
[--bootclasspath CLASSPATH]
[<-P|--output-params> OUT.params.txt] [<-D|--output-javadoc> OUT.xml] FILES
Provide --output-params OUT.params.txt, and the specified file will
be created which follows the file format laid out in
JavaParameterNamesLoader.cs:
package java.lang
;---------------------------------------
class Object
wait(long timeout)
Provide --output-javadoc api-javadocs.xml, and the resulting file
will be a class-parse-like XML file which uses //@jni-signature as
the "key" and a child <javadoc/> element to contain docs, e.g.:
<api api-source="java-source-utils">
<package name="java.lang">
<class name="Object" jni-signature="Ljava/lang/Object;">
<javadoc>…</javadoc>
<constructor jni-signature="()V">
<javadoc>…</javadoc>
</constructor>
<method name="wait" jni-signature="(J)V" jni-returns="V" returns="void">
<parameter name="name" jni-type="J" type="long" />
<javadoc>…</javadoc>
</method>
</class>
</package
</api>
This should make it possible to update the Xamarin.Android API documentation without resorting to web scraping (and updating the code to deal with whatever new HTML dialects are now used).
If neither --output-params nor --output-javadocs is used, then
--output-javadocs will be executed, writing to stdout.
The XML file also contains parameter name information, so that one file can be the "source of truth" for parameter names and documentation.
FILES can be:
- Java source code in a
.javafile; or - A file with a
.jaror.zipextension, which will be extracted into a temp directory and all.javafiles within the directory will be processed; or - A directory tree, and all
.javafiles will be processed.
If a single file references other types, the "root" directory containing
those types may need to be specified via --source DIR:
$ java -jar "bin/Debug/java-source-utils.jar" -v \
-s $HOMEandroid-toolchain/sdk/platforms/_t \
$HOME/android-toolchain/sdk/platforms/_t/android/app/Activity.java \
-P android.params.txt -D android-javadocs.xml >o.txt 2>&1
TODO:
In some scenarios, types won't be resolvable. What should output be?
We don't want to require that everything be resolvable -- it's painful, and possibly impossible, e.g. w/ internal types -- so instead we should "demark" the unresolvable types.
.params.txt output will use .* as a type prefix, e.g.
method(.*UnresolvableType foo, int bar);
docs.xml will output L.*UnresolvableType;.
Fix JavaParameterNamesLoader.cs to support the above.
1.16.1 Version 1.0.0.4
Villagers should no longer build walls on top of torches on steep slopes.
Villagers should no longer build walls in the air on steep slopes
The magic is leaving the land... Villagers are finding it harder to place levitating torches.
Villagers should no longer build walls on grasspaths or smoothsandstone on steep slopes.
In 1.16.1, villagers now the new smooth sandstone is used for roads so won't build on it.
Villagers should lose their magical ability to float torches in the air over walls.
Villagers are more able to clamber up a wall piece they just built.
One Note:
Villagers were never meant for dormitory life. If you place lots beds very close together, they will obsessively build fences. You can help them out by marking clean paths in and out of their bed area with smooth sandstone or grass paths.
Create LICENSE.md
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
although it's last month it's like yesterday fuck this i felt like this for a week i put a knife right in his eye my friend can't see