Typing mismatch for fontWeight property (maybe others?)

The problem
fontWeight has to be a string as per TTokens, but cannot be a string as per StyleXCSSTypes.
How to reproduce
I want to do:
// tokens.stylex.ts

import * as stylex from '@stylexjs/stylex';

export const typo = stylex.defineVars({
  fontWeight: '400',
});

// fontWeight has to be a string, as per @stylexjs/stylex/lib/StyleXTypes.d.ts:177:
// type TTokens = Readonly<{
//   [key: string]: string | { [key: string]: string };
// }>;

// MyComponent.tsx

import type { StyleXStyles } from '@stylexjs/stylex';
import * as stylex from '@stylexjs/stylex';

type Styles = {
  container: StyleXStyles;
};

const styles = stylex.create({
  container: {
    fontWeight: typo.fontWeight,
  },
});

// ...

BUT :
// @stylexjs/stylex/lib/StyleXCSSTypes.d.ts

// this cannot be an arbitrary string like '400'
type fontWeight =
  | 'inherit'
  | 'normal'
  | 'bold'
  | 'bolder'
  | 'lighter'
  | 100
  | 200
  | 300
  | 400
  | 500
  | 600
  | 700
  | 800
  | 900;

So I got:
Type 'StyleXClassNameFor<"fontWeight", string>' is not assignable to type 'StyleXClassNameFor<"fontWeight", Readonly<"initial" | "inherit" | "unset" | "normal" | "bold" | "bolder" | "lighter" | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | null | undefined>>

This is a bug in our type definition. Your usage is correct. Will fix.

@nmn can i take this please,
we only need replacement of that right ? from integer to string

Shouldn't font-weight support any arbitrary numbers?

type fontWeight should also support of type number (variable fonts) but I feel that for tokens, it should accept number values (other than just strings) and then from the create function reject using StyleXCSSTypes
ie: making a token for padding and spacing values as numbers

@kevintyj What does "arbitrary" mean in this context? As I understand it, arbitrary typically suggests that any number is acceptable. However, the CSS font weight attribute specifically requires a value between 1 and 1000. So sticking to values in the hundreds seems justified, and in line with the expected range. Correct me if I'm wrong.

@kevintyj There are some types functions that I'm working on that will make some of this better. We don't accept number values for tokens yet because while StyleX will usually convert numbers to px values based on the property name, variables don't have a type.
In the meantime we have two options:

Add string equivalents for all the number values: '100' | '200' | .... This is safe and would compile to exact same thing.
Simply add string | number at the end of the list of types. This would allow arbitrary number values that are not multiples of 100.

Considering the increasing use of variable fonts, I think option 2 is good for this.
@purohitdheeraj You are welcome to put up this PR, but be prepared for some discussion about the better option mentioned above.

@nmn

Considering the increasing use of variable fonts, I think option 2 is good for this.

I agree that option 2 would be a better temporary fix until the new type function is adopted! The only downside being that arbitrary number would not satisfy type def of TTokens as it only accepts string

@kevintyj You‘re right but I guess this approach in the following would work. So basically we would just have to change this. If I understand this right, this allows strings “400”, “bolder” and numeric values like 400?

/packages/stylex/src/StyleXTypes.js

type TTokens = $ReadOnly<{
  [string]:
    | number
    | string
    | $ReadOnly<{ default: number | string, [string]: number | string }>,
}>;

@timwehrle The nested object case is handled elsewhere. The fix would be as simple as:
type fontWeight =
  | 'inherit'
  | 'normal'
  | 'bold'
  | 'bolder'
  | 'lighter'
  | 100
  | 200
  | 300
  | 400
  | 500
  | 600
  | 700
  | 800
  | 900
  | string
  | number;

arbitrary number would not satisfy type def of TTokens as it only accepts string

Yeah, as explained we cannot accept raw numbers as variable values. It is error prone because you may expect some number to be auto-converted to px values which won't happen.
The types function will let you do something like this, which should solve it:
const vars = stylex.defineVars({
  heavy: stylex.types.number(700),
  red500: stylex.types.color('tomato'),
  size_lg: stylex.types.length('64px'),
  // And I'm thinking about the following patterns:
  size_sm: stylex.types.rem(2),
  size_md: stylex.types.px(36),
  // Further, I want something like this, but it needs to be immutable/unthemeable:
  media_mobile: stylex.types.media('(max-width: 480px)'),
});

StyleXCSSTypes.d.ts

It should work? I just tested it out and was able to make a commit to that file. Perhaps check your local gitignore config?

@purohitdheeraj Please edit the .js file in src/. StyleX is authored in Flow and the TS types are generated from that. You're looking for StyleXCSSTypes.js.
After that, running npm run build will update the auto-generated StyleXCSSTypes.d.ts with the new type.

Thank you so much @nmn and @kevintyj
just raised a PR for it


Rename the Spm package manager to SwiftPM

Align the name with upstream terminology.
See individual commits.
Fixes #8134.

The failing test is unrelated.


fixed issue where extra spaces added to class attr

when ever a class was added to a node, regardless of if a space was present at the end of the class attribute an additional one was added to ensure the new class was not appended to the end of the last class. This caused an ever increasing amount of spaces in the class attribute. Updated the addClass function to trim the current value of the class attribute, append a space and then append the new class

This appears to be fixed by 4bce5342 . Next time, when adding a patch to a pull request, also add a comment, so that the repo owner gets notified that you want something reviewed.


Get cabal matching up with the source files.

Remove src/Twilio/Types/TwilioT.hs since it wasn't being used.
Add Twilio.Types.Issue to the other-modules section of the cabal file.
This prevents the following bug from occuring when other application try
to use the twilio library:
<no location info>:
    <command line>: can't load .so/.DLL for: /home/traveller/code/fanjam/fanjam-api-servant/api/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.1/twili_HwROPXwVgDK34Z4up189Jn/libHStwilio-<IP_ADDRESS>-HwROPXwVgDK34Z4up189Jn-ghc7.10.1.so (/home/traveller/code/fanjam/fanjam-api-servant/api/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.1/twili_HwROPXwVgDK34Z4up189Jn/libHStwilio-<IP_ADDRESS>-HwROPXwVgDK34Z4up189Jn-ghc7.10.1.so: undefined symbol: twilizuHwROPXwVgDK34ZZ4up189Jn_TwilioziTypesziIssue_zdfEqIssue_closure)
[ 6 of 26] Compiling Web.Fanjam.Internal.Core ( Lib/Web/Fanjam/Internal/Core.hs, dist/build/Web/Fanjam/Internal/Core.o )

<no location info>:
    ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-unknown-linux):
	Dynamic linker not initialised

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I think this is the last one for now:)

Oh my, good catch! Thanks as always @seagreen. Still waiting on travis-ci builds to work (for an unrelated reason it looks like)... I'd like to get a green build by this evening before pushing to Hackage.

You're welcome. Re: waiting on the build: that sounds good to me.

Hey @seagreen, build is working now and I've uploaded twilio <IP_ADDRESS> to Hackage. Though I must admit I only glanced over Twilio.Types.Issue being added to other-modules and not exposed-modules—can you explain more why you needed this? I'd like to move it to exposed-modules in subsequent releases.

If it's not included in either exposed-modules or other-modules it gives me a build error in my application that uses twilio-haskell. I don't care which one though, so if it's meant to be exposed by all means move it to exposed-modules.
It's strange behaviour. You would expect that leaving it out would cause twilio-haskell to fail to build, but instead it causes applications using twilio-haskell to fail to build. Weird.


Create huggingface dataset

This dataset will be used for our modeling purposes, and ease of reproducibility. We need the audio file, stock price of company before and after the call.

Stock price may not be necessary until modeling work is to be conducted


SCP-5000: Added basis of Asset preservation theory

As part of the Marlowe audit, a discrepancy was found regarding the MoneyPreservation.thy theory. We state in plain English that when we compute a transaction the money is preserved. This means that no assets are created or destroyed during a transaction. The problem is that the theorems inside MoneyPreservation.thyonly refers about the quantity of tokens and don't guarantee that the same token is preserved. This means that the proofs don't guarantee us that if we deposit 15 ada and 20 djed we won't get 15 djed and 20 ada back.
To address this I created the AssetsPreservation.thy theory, which introduces a new typedef Assets that represents Multi-token assets. I've added multiple class instances to allow arithmetic on the new type and completed proving that reduceContractStep preserves assets.
Before going further and proving that computeTransaction and playTrace preserves assets (with all the intermediate functions), I wanted to take a small sanity check to see that the proofs are going in the right direction.
Most of my concerns are expressed as TODO: comments in the code, but I explain the most important one here:
Account representation
The Semantics.thy theory, which is the subject of the proofs, works with accounts represented as an associative list
type_synonym Accounts = "((AccountId × Token) × int) list"

and it uses the functions insert, delete and lookup defined in the MList.thy theory. This is well suited for an executable definition, as Plutus also works with associative lists, but is harder to reason about.
In the second section of AssetsPreservation.thy I defined another type synonym for Accounts as a Map.
type_synonym Accounts = "AccountId ⇀ Assets"

My main issue here is that in order to prove stuff for the executable definition I still need to make lemmas around the associative list representation, which are harder to do (look for example at assetsInAccounts_distrib_on_update). I tried to map the list version to Map version in lemmas like moneyInAccountFromSemantic, but for the moment I wasn't able to prove them. Another thing I did to aleviate this problem was to add a MList_induct lemma in MList, to be able to do induction in lists the same way I do it for Maps.
Another issue that I have is that I need to propagate assumptions like valid_map acc and allAccountsPositive acc when I'm using the List representation, and finite (dom acc) when I'm using the Map representation. I though of creating a typedef with the finite restriction, but I'm wondering if that won't involve in also having to re-define/transfer a lot of the Map lemmas. The question here would be, what is the rule of thumb for using a type_synonym vs typedef, and is there any way to easily expose the underlying lemmas of Map if I use a typedef?
A side note on the List representation using an int and the allAccountsPositive restriction: I found it a little bit harder to work with nat rather than int as they form a semiring instead of a ring, so in order to simplify something like a + (b - a) = b I first need to prove than a ≤ b (a and b being Multi-token Assets).
A final note on this section, the audit also pointed out that MList implementation differs from the Plutus AssocMap implementation. For example:
AssocMap.insert 'a' 1 [('b', 0)] == [('b', 0), ('a', 1)]

MList.insert 'a' 1 [('b', 0)] == [('a', 1), ('b', 0)]

We could easily change MList to behave the same as AssocMap, but that is not ideal as the Marlowe specification should be blockchain agnostic. I wonder what is the best solution for this problem. My intuition tells me that if I define a typedef around Isabelle Map with the finite restriction, I should probably use that in the Semantics.thy code as well, then investigate on how to use code equations to use a particular implementation (like MList). If we do this, we should also add some property based tests in the marlowe-spec-test tool to check properties likeinsert k v1 (insert k v2 m) = insert k v1 m, but don't rely on the order of entries.

Close in favour of PR 161, which ended up being easier to prove