Jest mocks not being correctly applied for each scenario

I noticed some odd behaviour when mocking methods in scenarios.  It appears that the last scenario's mock applies to all of the tests, as opposed using the mocked value in each scenario.
Here is a contrived example for now, as I don't have my code in github
Test step file
import fnTest from "../../fnTest";
import { functionUnderTest } from "../../fileUndertest";

const mockFn = jest.fn();
jest.mock("~/fnTest", () => {
  return jest.fn().mockImplementation(() => {
    return { testFn: mockFn };
  });
});

const feature = loadFeature("../features/test.feature", { loadRelativePath: true });

defineFeature(feature, test => {

  test("Testing scenario 1", ({given}) => {
    mockFn.mockReturnValue("test1");
    given("just testing 1", () => expect(functionUnderTest).toEqual("test1"));
  });

  test("Testing scenario 2", ({given}) => {
    mockFn.mockReturnValue("test2");
    given("just testing 1", () => expect(functionUnderTest).toEqual("test2"));
  });
});

fnTest class
class fnTest {
  constructor() {}
  testFn() {
    return "test"
  }
}

export default fnTest;

fileUndertest
import fnTest from "./fnTest";

export const functionUnderTest = () => {
  const x = new testFn();
  return x.testFn();
}

What actually happens is:

"Testing scenario 1" will fail asserting that "test2" is not equal to "test1"
"Testing scenario 2" will pass asserting that "test2" is equal to "test1"

If I swap the order of scenarios in my feature file, the inverse test results will happen, meaning that "Test scenario 2" will fail and "Test scenario 1" will pass.
What I expect to happen is that "Testing scenario 1" correctly sets the mocked return value such that I the assertion will pass.

@number33 you should check out cucumber-jest, it doesn't have this problem. it's a jest transformer for executing cucumber tests with jest. It allows you to use the cucumber api to define steps, hooks, world, etc. and not a custom api like this library.

I'm having the same issue with mock.spyOn, is there really no way around this ?


Inconsistent order of channels

I have a number of 8-channel USB sound devices on a Linux/ALSA system. Each device 4 3.5mm outputs - one for each of Front, Surround, Centre/Bass, Back. I'm using an OutputStream with callback to send data to these devices. The problem is the channel mapping within a device is not consistent, either across devices or across runs of my program, or reboots. So sometimes the first physical output jack (Front) corresponds to the first two channels in my output stream, sometimes it's the 3rd & 4th channels, etc etc.
Any ideas how to make this consistent, or at least be able to read what output a channel is going to so I can map accordingly?

The list of devices is provided by the underlying PortAudio library (which in turn somehow gets it from ALSA), and from the Python side you only get the device name, which might not help in your case.
You should ask about this in the PortAudio mailing list or issue tracker: https://portaudio.com/contacts.html
However, I think this is a known problem and has been discussed many times, and I don't think there is a straightforward solution ... but who knows, you should still ask!

I've re-created the issue using alsa, so it seems it's a problem at that level, not at sound-device or portaudio. https://github.com/alsa-project/alsa-lib/issues/402


Not sending phone verification code

Describe the bug
Sagemaker not sending the phone verification code i need to start a runtime its been days already

Could you please check the FAQ: Why did I get an error when I entered my phone number section? Some kinds of number format is not supported in Studio Lab.
https://github.com/aws/studio-lab-examples/issues/159

Thank you for reporting this issue. We appreciate you taking the time to provide feedback.
Upon reviewing the issue, it appears there may be a formatting issue with the phone number provided. Could you please double-check the phone number format?
https://studiolab.sagemaker.aws/faq

There may be several causes to this error: Make sure the number is in an E.164 format, and that it is not a VoIP or landline number. If the phone number meets those requirements but you still get the error, wait a few minutes and try again.

Please feel free to reach out if you have any other questions or concerns. We're here to help and look forward to working with you to resolve this matter.


cell.output depends on when you access it

the cell objects returned by beaker.getCodeCells have a output field, it can either be just a string or an object depending on when you call it.  see the following notebook and check the console
http://sharing.beakernotebook.com/gist/anonymous/9b1961478327b3c1aa24
i get these two lines
 look, no semicolon!
Object {selectedType: "Text", elapsedTime: 39, state: Object, result: "look, no semicolon!"}

This should be resolved in the PR for serialization


Add Design Documents

Utilizing design tools such as Figma or Sketch, create a UI/UX document and link it to the repository

The document is already created and maintained by Michell S.


webpack hangs in middle when '--p' is used always on 68%

I am using vuejs Loader. When I run the command "production"  === "webpack --p --progress". It always get struck at 68% and keeping stucking there forever. Can anyone suggest why is this happening and how can I resolve this.

this is my web.config.js
var webpack = require('webpack');
var StatsWriterPlugin = require("webpack-stats-plugin").StatsWriterPlugin;
var OfflinePlugin = require('offline-plugin');

module.exports = {
  entry: {
    build: './src/index.js',
    restJS: './src/restJS.js'
  },
  output: {
    path: './dist',
    publicPath: 'dist/',
    filename: '[name].js'
  },
  module: {
    loaders: [{
      test: /\.vue$/,
      loader: 'vue'
    }, {
      test: /\.js$/,
      loader: 'babel',
      exclude: /node_modules/,
      query: {
        presets: ['es2015'],
        plugins: ['transform-runtime']
      }
    }, {
      // edit this for additional asset file types
      test: /\.jpe?g$|\.gif$|\.png$|\.svg$|\.woff(\d*)\??(\d*)$|\.ttf\??(\d*)$|\.wav$|\.mp3$|\.eot\??(\d*)$|\.svg\??(\d*)$|\.html$/,
      loader: "file-loader"
    }, {
      test: /\.scss$/,
      loader: "style!css!sass"
    }, {
      test: /\.css$/,
      loaders: ["style", "css"]
    }]
  }

};

this is my package.json
{
  "name": "",
  "version": "",
  "description": "",
  "author": "",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "webpack --progress --colors --watch",
    "watch" : "webpack --progress --colors",
    "dev": "webpack-dev-server --watch --inline --hot",
    "build": "webpack --progress --colors --watch --optimize-dedupe --optimize-max-chunks 15 --optimize-min-chunk-size 10000",
    "analysis":"webpack  --json | analyze-bundle-size",
    "production": "webpack --p --progress"
  },
  "dependencies": {
    "babel-plugin-transform-runtime": "^6.1.18",
    "css-loader": "^0.23.0",
    "file-loader": "^0.8.5",
    "google-maps": "^3.1.0",
    "hammerjs": "^2.0.4",
    "install": "^0.3.0",
    "jade": "^1.11.0",
    "jquery": "^2.1.4",
    "materialize-css": "^0.97.3",
    "node-sass": "^3.4.2",
    "npm": "^3.5.0",
    "opentok": "^2.3.0",
    "sass-loader": "^3.1.2",
    "style-loader": "^0.13.0",
    "template-html-loader": "0.0.3",
    "testimonial": "^2.0.1",
    "url-loader": "^0.5.7",
    "vide": "^0.4.1",
    "vue": "^1.0.10",
    "vue-async-data": "^1.0.2",
    "vue-hot-reload-api": "^1.2.1",
    "vue-html-loader": "^1.0.0",
    "vue-loader": "^7.1.4",
    "vue-resource": "^0.1.17",
    "vue-router": "^0.7.7",
    "vue-validator": "^1.4.4",
    "webfont-medical-icons": "^0.9.3",
    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.0"
  },
  "devDependencies": {
    "babel-core": "^6.2.1",
    "babel-loader": "^6.2.0",
    "babel-preset-es2015": "^6.1.18",
    "babel-runtime": "^6.2.0"
  }
}

Maybe as a workaround you could get a non-minified output from Webpack and then pass it through Uglify separately. I know that's not neat but at least it would allow you to get ahead.
Possibly related issue: #537.

I am getting an non-minified file and then minifying with php but after this also its size is still 1MB

Check out the bundle carefully. It's probably bringing things there you might want to include.
Based on your setup it will inline CSS within the bundle. Consider setting up ExtractTextPlugin to get a separate bundle for CSS.

@bebraw after extracting css, build.js is reduce by 18kb so practically its still of 1MB.

@S1E- Yeah. There is something else going on. Perhaps some of your vendor dependencies are heavy or it includes code you don't want it to. There are tools like Webpack Chart that can give you a better idea.

Size analysis of my build.js is

webpack chart map of build.js

Particularly materialize-css and crypto-js seem really big. You could try to analyze how you are using those. Maybe you just need a smaller subset of each.
You can load a dependency like jquery as an external. There are also code splitting techniques you can leverage.
To get back to the original issue, it would help a lot if you could set up a simplified test case that demonstrates the hang. Strip as much code as you can. This will make it easier to debug.

Can you please suggest me to some resource? Where I can see that how I can I write a test to debug this issue.

Essentially it would be about dropping as much material from your project while retaining the hang. At some point it will stop failing so you may need to step back.
You can try eliminating entire pieces of the project like styling for instance. There isn't any specific resource as it's just generic debugging to pinpoint the cause. :+1:
Hopefully this process helps you to understand what triggers the issue.

I have already tried that, all the files included in the bundled are used somewhere so when I remove any one of them then webpack throws error 'required file not found'

Yeah, you would have to perform the changes on code level on a separate branch. No other way.

OK and thanks

You could try the 2.0.7-beta version, which displays the module name in the progress thing. Maybe this helps to identify the point where it hangs..

I tried 2.0.7-beta but the message is similar, no mention of the module name. It was "additional asset processing"

I'm seeing the same issue and not uglifying.  Today I did an npm install, first time in about a week.  So I think something changed recently to cause this.
I consistently see this:
10% 0/2 build modulests-loader: Using<EMAIL_ADDRESS>and /Users/JARVIS/src/project7/tsconfig.json  68% 120/123 build modules
68% or 69% is the consistent mark with 119-121/123 built.
Isn't there any way to get more info on what's going on under the covers?

Facing same issue, but I noticed one thing that it's not happening for
devtool: 'eval', but is happening for both:
devtool: 'source-map'
and
devtool: 'cheap-module-source-map'

Can you try against the current beta version of webpack 2?

Hello, I have the same issue with webpack 2.2.0-rc.3 and webpack.2.1.0-beta.28
It's blocking at 91%. No minification, no sourcemaps.
I'm using extract plugin (2.0) and awesome typescript loader.

@clemgrim Could you set up a project so it's easier to debug what's going on?

Here is my config:
// load required modules
var path = require('path');
var webpack = require('webpack');
var autoprefixer = require('autoprefixer');

// load plugins
var CopyWebpackPlugin = require('copy-webpack-plugin');
var AssetsPlugin = require('assets-webpack-plugin');
var ExtractTextPlugin = require('extract-text-webpack-plugin');
var NgAnnotatePlugin = require('ng-annotate-webpack-plugin');

module.exports = function(options) {
   return {
        entry: {
            home: '/some/path/home.ts', // there're more entries
            vendor: '/some/path/vendor.ts')
        },
        output: {
            path: '/some/path/dist',
            filename: '[name].js',
            chunkFilename: '[id].chunk.js',
            publicPath: '/dist/',
            jsonpFunction: 'jsp'
        },
        resolve: {
            extensions: ['.ts', '.js'],
            modules: ['/some/path', 'node_modules'],
            unsafeCache: true
        },
        resolveLoader: {
            moduleExtensions: ['-loader']
        },
        module: {
            loaders: [
                {
                    test: /\.ts$/,
                    loader: 'awesome-typescript',
                    exclude: [/node_modules/]
                },
                {
                    test: /\.html/,
                    loader: 'html',
                    exclude: [/node_modules/]
                },
                {
                    test: /\.css$/,
                    loader: ExtractTextPlugin.extract({fallbackLoader: 'style', loader: options.prod ? 'css!postcss' : 'css'})
                },
                {
                    test: /\.scss/,
                    loader: ExtractTextPlugin.extract({fallbackLoader: 'style', loader: options.prod ? 'css!postcss!sass' : 'css!sass'})
                }
            ],
            noParse: [
                /angular.*\.js$/,
                /moment.*\.js$/,
                /ui-select.*\.js$/,
                /pdfjs-dist.*\.js$/,
                /ngmap.*\.js$/,
                /ng-file-upload.*\.js$/
            ]
        },
        plugins: [
            new webpack.optimize.CommonsChunkPlugin({names: ['vendor']}),
            new ExtractTextPlugin(options.prod ? '[name]-[chunkhash].css' : '[name].css'),
            new webpack.DefinePlugin({PRODUCTION: !!options.prod}),
            new AssetsPlugin({filename: 'manifest.json', path: absPath('data/webpack')}),
            new webpack.LoaderOptionsPlugin({
               minimize: options.prod,
               debug: false,
               options: {
                  htmlLoader: {
                     ignoreCustomFragments: [/\{\{.*?}}/],
                     attrs: false
                  },
                  postcss: function () {
                     return options.prod ? [autoprefixer] : [];
                 }
              }
            }),
            new NgAnnotatePlugin({add: true})
        ],
        node: {
            global: false,
            crypto: false,
            module: false,
            clearImmediate: false,
            setImmediate: false
        },
        devtool: false,
        profile: true,
        performance: {
            hints: false
        },
        stats: 'verbose',
        watchOptions: {
            ignored: [
                './node_modules/**/*',
                './module/**/*',
                './public/**/*',
                './vendor/**/*'
            ]
        }
    };
};

It takes ~25s (I optimized from 35 to 25s with noParse option)
But the  91% additional asset processing is taking a very long time, and I can't figure what is done in this step. there's no uglify plugin or whatever.
Note that I'm building 600+ modules

Same problem here, hangs on 91% additional asset processing

Same here for us.

Same for me, but on 66%

The weird thing for me is that, with the exact same versions of node, npm, yarn, and all of the packages, I can run this on my Macbook Pro (macOS 10.12.3 with 16 GB RAM and SSD) and it will finish in about 50 seconds.  On my Ubuntu 16.04 servers (8GB RAM AWS with SSD), it takes 15 minutes (hanging at 68% for a long time but it does eventually finish).  So I have to perform the build step on my mac and then rsync the files to the servers.
Has anyone else experienced this where it will work on a Mac in a reasonable amount of time but it's dog slow on a Linux server with the same build tools?

@mstralka I am also experiencing this on a Macbook Pro. Do you know if it is possible to debug this?
I just see the following with the --progress flag set:
64% building modules 1158/1265 modules 107 active ...e_modules/lodash/isArrayLikeObject.js

@mikeengland unfortunately I don't know how to debug why it works okay on a mac but so slow on Linux.
I do know that it appears to be related to compiling SASS because if I remove the steps that compile my SASS files from the build script, it works much faster on Linux too.  I'm using these SASS-related packages:
yarn list | grep sass
├─<EMAIL_ADDRESS>│  ├─<EMAIL_ADDRESS>│  ├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  ├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>
yarn --version
0.21.3
npm --version
4.1.2
node --version
v7.6.0

I saw other issues relating to sass compilation on Github. Sadly, I'm not compiling any SASS! It seems that since the webpack 2 upgrade, the npm compilation sporadically takes 5+ mins :(.

Same with me, it hangs on 91% and I am using Windows 10 and not compiling SASS.

Facing same issue. Hangs randomly, I am running webpack --config config/webpack.dev.js --progress --profile

Same with me. I faced this issue using latest node realises (7.4.0, 7.5.0). Have fixed it moving to the node 6.9.5.

Same here. Switching node versions didn't fix it. It may be worth mentioning that in the past week that I've also had trouble importing external sass modules (i.e. node-bourbon), throwing a path not found.
yarn 0.21.3
node 7.6.0
npm 4.1.2

Found this in some other thread. I was able to fix it after setting UV_THREADPOOL_SIZE=100 in the env.

@subhash-periasamy how did you invoke this? i tried it a few different ways and it didn't work.

make sure you have it in your env. I am using mac so I did:  export UV_THREADPOOL_SIZE=100

I think this might be the related issue on node-sass:
https://github.com/sass/node-sass/issues/857
But setting UV_THREADPOOL_SIZE=100 isn't helping on my linux box.  It still hangs for 15 minutes at 69%

@henrahmagix Here you go https://github.com/webpack-contrib/sass-loader/issues/100
But this thread is pretty old however it helped my scenario. Initially I tried to delete portions of my webpack config to see what is causing the hang and narrowed down to the sass-loader.
Then I started searching for sass-loader hang and came across the thread. Hope it helps!
Below snippet was causing the hang:
 {
                test: /\.scss$/,
                loaders: ['raw-loader', 'sass-loader']
             },
             {
                test: /initial\.scss$/,
                loader: ExtractTextPlugin.extract({
                    fallbackLoader: 'style-loader',
                    loader: 'css-loader!sass-loader?sourceMap'
                })
             },

I am not using sass-loader and facing same issue with hanging on 91%

Same here.

Face the same issue, hangs on 91% additional asset processing.
The issue will not happen if I do one of the following things:

Set devtool to some value that contains eval (eval, eval-source-map , cheap-eval-source-map, etc.)

Remove the UglifyJsPlugin.

I have similar issue , hangs on  91% additional asset processing too long.
My solution is use 'webpack-parallel-uglify-plugin' to replace UglifyJS plugin;
hopes help
var ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin');
new ParallelUglifyPlugin({
   cacheDir: '.cache/',
   uglifyJS:{
     output: {
       comments: false
     },
     compress: {
       warnings: false
     }
   }
 })

Big codebase (jquery + typescript + new code with angular 4)
node: 6.10.x
webpack: 2.5.1
Production build time about 20 min with devtool: source-map. Stuck on "91% additional asset processing"
Change to devtool: cheap-module-source-map didn't help, build time still about 20 min
Change to devtool: cheap-module-eval-source-map helped, the build time was reduced to 2 minutes

@andrexx Do you have both ts-loader/awesome-ts-loader and babel-loaders in your setup?

@dziamid Only awesome-typescript-loader (^3.1.3)

@andrexx Try using ts-loader in traspile-only mode

Having the same problem. Gets stuck at 91% additional asset processing :(

@milanchheda Any luck with fixing it?

@yantakus - So I moved from t2.micro to t2.small and it got fixed. I believe, it needs high configuration as the consumption is very high when it merges & combines files.

I also have this problem I hit the 91% additional asset processing and then it stalls for ~10-15min
I cut it down setting the devtool to eval just to test it and then the build time was 81s instead of 10min but there must be a way to skip the asset processing ?

Same problem, anyone have a good workaround for this?

I am having the same issue. With the -p option, the build takes about 10 minutes, handing around 30% but never in the same spot. Using any of the "eval" source map options fixes it but then the resulting file is much larger.

same issue here with node 8.4.0

Our production build is also failing after 91% additional asset processing with FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory.
We cannot skip minification or tree-shaking, as this would yield an unwieldy large application that is quite slow to load.

I found a workaround for us
We replaced all webpack calls from our build scripts with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js.
In this case, we increased the node memory limit to 6GB (default seemed to be 1.5GB). Our build was hitting ~3GB, I went with 6GB as a limit to leave some headroom.
Comparison of old vs "fixed" solution

from build script (in this case: patched into dotnet publish with an <Exec Command="…"> - because we build an asp.net core application)
from package.json

new "fixed" workaround
# build script
node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js --config config/webpack.config.vendor.js --env.prod -p

# package.json scripts:
"build-webpack-prod-vendor": "node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js --config ./config/webpack.config.vendor.js --env.prod -p",

previous implementation
# build script
node_modules/webpack/bin/webpack.js --config config/webpack.config.vendor.js --env.prod -p

# package.json scripts:
"build-webpack-prod-vendor": "npm-run webpack --config ./config/webpack.config.vendor.js --env.prod -p",

Summary
Replaced npm-run webpack … with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js …
Replaced node_modules/webpack/bin/webpack.js … with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js …
Adjust --max-old-space-size=<maximum memory in MB> accordingly.

@urbanhusky icreasing the max memory does indeed fixed the hangs on 68-69%. thanks for that!

For everyone experiencing the 91% hang, let's get https://github.com/webpack/webpack/issues/4558 reopened. node --max-old-space-size=6144 does not help with that problem.
There has been some discussion there, but the issue has been closed prematurely.

I'm getting stuck at 70% with webpack 4.0.1:
❯ webpack --progress
 70% building modules 1682/1682 modules 0 active

@mnpenner can you create minimum reproducible test repo?

@mnpenner Have you tried increasing your NodeJS memory limit?  I'm going to fight with it a bit more first. My config is rather complex.
@montogeek No, I haven't tried that. I should do something like this?
❯ node  --max-old-space-size=8192 "node_modules/.bin/webpack" --progress --color --sort-assets-by name --bail

Same result. It's not crashing though, so it doesn't seem like it's running out of memory.
My project has 514 "assets" -- I think all or most of those are processed by webpack.
The part I find weird though is that it says "1691/1691 modules 0 active" -- as though it's done. It seems like its getting confused.
I guess I'll wait for the v3 to v4 migration guide. Probably missed something. webpack-dev-server still runs, its just my production build that's hanging.

@mnpenner try to enable/disable plugins and loaders

@mnpenner I had the same problem and for me the cause was extract-text-webpack-plugin. Switching to mini-css-extract-plugin solved it.

Thanks Jack. That worked for me too (switching to mini css)
On Mar 27, 2018 12:53 AM, "Jack Tomaszewski"<EMAIL_ADDRESS>wrote:
@mnpenner https://github.com/mnpenner I had the same problem and for me
the cause was extract-text-webpack-plugin. Switching to
mini-css-extract-plugin solved it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/2012#issuecomment-376430805,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABD7phI-EC4S-5jFvxm_G67PP8BUrK0Yks5tie_9gaJpZM4HU1aB
.

FYI webpack@2 is deprecated. Please upgrade you configuration to latest version and feel free to recreate issue if problem still exists. A lot of difference issues here and difficult support people. Thanks!

I had a similar issue, google pointed me here. Leaving my findings for the future.
For me, it was related to https://github.com/sass/node-sass/issues/857
For me, it only existed on webpack-dev-server with node-sass on Windows.
I resolved it by adding
UV_THREADPOOL_SIZE=1024 to my package.json build scripts
    "run-dev": "cross-env DEV='true' NODE_ENV=development BABEL_ENV=development NODE_OPTIONS=--max_old_space_size=8192 webpack-dev-server --config webpack.dev.js --progress --color",
    "run-dev-windows": "cross-env DEV='true' NODE_ENV=development BABEL_ENV=development NODE_OPTIONS=--max_old_space_size=8192 UV_THREADPOOL_SIZE=1024 webpack-dev-server --config webpack.dev.js --progress --color",

It slowed down my linux builds, so I split it into two scripts. But it turned my windows builds from never-finishing always-hanging to actually-completes (in about 3.5 minutes)

For me, it was related to sass/node-sass#857

Thank you very much for this hint.  webpack was hanging at the end of a run unless I set stats: 'none' or didn't apply sass-loader (redundantly) for CSS files.


Losslessly compress PNGs

Some of the images on the website are much larger than they need to be, for example one of the of the sponsor logo images is 5692x3200 but displayed at 250x120!
All the sizes:

400x400
1014x514
1024x373
1024x373
1164x638
1368x700
1394x718
1568x830
1572x906
1576x888
1634x910
1686x888
1698x864
1728x972
1766x976
1792x1022
1800x1200
1904x1520
1910x760
2030x1138
2133x1200
2133x1422
2317x1434
2480x3508
2480x3508
2483x3508
2500x1200
2662x1576
3279x1785
3453x2177
3508x2481
3508x2481
5692x3200
6461x3634
6461x3634

These should really be resized to something closer to their display size (the same applies to WEBP images). I've not done that here.
Instead, I've losslessly compressed the PNGs https://github.com/shssoichiro/oxipng (it's a multithreaded version of optiPNG to reduce their total size by about 15% from 93 MB to 79 MB, using the command git ls-files "*.png" | xargs oxipng -o max --strip all
24619 bytes (19.17% smaller): public/favicon.png
44673 bytes (29.65% smaller): public/img/eps-logo.png
499687 bytes (35.39% smaller): src/images/rooms/level-5-foyer.png
87298 bytes (18.24% smaller): public/social-card.png
338084 bytes (48.44% smaller): src/images/rooms/forum.png
118658 bytes (11.87% smaller): src/content/sponsors/kraken.png
464113 bytes (52.19% smaller): src/images/rooms/liffey-hall-1.png
155930 bytes (20.81% smaller): public/social_card_remote.png
219563 bytes (48.57% smaller): src/images/rooms/ground-floor-foyer.png
553604 bytes (53.35% smaller): src/images/rooms/level-1-foyer.png
419777 bytes (51.24% smaller): src/images/rooms/liffey-a.png
178127 bytes (46.36% smaller): src/images/rooms/level-2-foyer.png
7878246 bytes (14.14% smaller): src/content/deadlines/hall_rotated.png
41995 bytes (65.67% smaller): src/content/sponsors/packt.png
494986 bytes (52.66% smaller): src/images/rooms/liffey-hall-2.png
434471 bytes (13.21% smaller): src/images/rooms/liffey-meeting-room-2.png
486164 bytes (52.58% smaller): src/images/rooms/liffey-boardroom-3.png
406887 bytes (51.34% smaller): src/images/rooms/liffey-boardroom-4.png
357845 bytes (51.47% smaller): src/images/rooms/wicklow-hall-1.png
1046941 bytes (42.93% smaller): src/images/rooms/level-3-foyer.png
44905 bytes (29.35% smaller): public/img/eps-logo-white.png
55288 bytes (72.30% smaller): src/content/pages/images/accessibility-references.png
239026 bytes (19.63% smaller): public/sponsor-swag/googlecloud-swag.png
268126 bytes (49.05% smaller): src/images/rooms/wicklow-hall-2.png
280206 bytes (49.28% smaller): src/images/rooms/ecocem.png
1359849 bytes (6.36% smaller): src/content/pages/images/accessibility-first-floor-map.png
413331 bytes (31.50% smaller): src/content/pages/images/accessibility-second-floor-map.png
1450394 bytes (25.70% smaller): src/content/pages/images/accessibility-map.png
752276 bytes (15.28% smaller): public/sponsor-swag/numberly-swag-0.png
2868132 bytes (13.47% smaller): src/content/pages/images/sprints-collage24.png
1071445 bytes (7.28% smaller): src/content/pages/images/accessibility-ground-floor-map.png
816263 bytes (11.23% smaller): src/content/pages/images/accessibility-parking-map.png
5650859 bytes (14.16% smaller): public/sponsor-swag/numberly-swag-1.png
26861661 bytes (7.31% smaller): src/images/cards/volunteers-23.png
26861661 bytes (7.31% smaller): src/content/deadlines/volunteers-24.png

@hugovk mmh, I don't think this would change much, since we are using Astro to optimise the images
Not sure why it is not resizing the sponsor ones well though 🤔

should be fixed after merging this: https://github.com/EuroPython/website/pull/781

I think we could close this, I don't think we need to optimise the source images, unless we want to save space on the git repo (but then we'd need to purge the previous images from the history too), what do you think?

Larger files are still being served, even after merging #781.
I checked two files from the website (favicon.png and social-card.png) and they're still the bigger sizes (30k and 104k) rather than the smaller ones in this PR (24K and 85k).

@hugovk which ones?
for favicon and social, we can update them 😊

These ones:
https://ep2024.europython.eu/favicon.png
https://ep2024.europython.eu/social-card.png


Error: “/keybase is unavailable. Please try again.”

Windows 10, 64-bit. I installed Keybase over a year ago, used it for a couple of things I wanted to use it for at the time, then ceased using it. Somewhere along the way I disabled the startup items that it installs.
Just now I wanted to start using it again; I tried starting it (without the background startup items having been started), but it got stuck on “Loading…” when I started it. After one attempt to start the background task, I decided to just uninstall it and install the new version of it. I did so.
I seem to be logged in already (despite uninstalling Keybase), though I wasn’t storing anything in kbfs before. The K: drive seems to be working.
I started the GUI, switched screens a few times. When I wound up in Settings, some seconds later an error popped up:

/keybase is unavailable. please try again.
Error: /keybase is unavailable. please try again. at b.default.readdir (file:///C:/Users/me/AppData/Local/Keybase/Gui/resources/app/desktop/dist/index.bundle.js:11:561202) at FSReqWrap.oncomplete (fs.js:114:15)

I don’t know if this is significant or not at this stage. But it’s worth mentioning here, at the least.

Thanks for the report.  If you do a keybase log send from the Keybase Shell, and let us know the resulting ID here, that would be very helpful.
cc: @zanderz


new typeof keyword

I've added a new keyword typeof that returns the type of the expression as a string (typeof(4+3) == Num). Can be useful for error messages:
class Plane {
  pilot=(value) {
    if(!(value is Pilot)) {
      IO.print("Error: 'Pilot' expected got '", typeof(value), "'.")
    }
  }
}

var p = new Plane
p.pilot = 3 // print "Error: 'Pilot' expected got 'Num'."

if you (Bob or any Wren-user) have any comment, remark, anything, feel free!
ps: I couldn't run the tests (yay, windows!), but I assume I didn't broke anything and wrote the new tests properly.

Personally, I think I would expect typeof to return the type of its argument rather than the name of the type.

I thought about the JS typeof while writing the thing (and I'm not fully fluent in Wren), but that's probably a better option.

Hmm, on second thought I'm afraid this just needlessly duplicates Object.type. Or do you see any advantage of having this as a keyword?

none, I just didn't know that existed. (but nonetheless it was fun hacking wren internal).

Yup, like @bjorn says, this is redundant with .type. I'm still glad you tried this out though, because I'm sure it's a good learning experience. :)


add specific testable requirements

The Contents of a PRD
Title: Give this project a distinct name.
Change History: Changelog
Overview: Briefly, what is this project about?  Why are you doing it?
Success Metrics: What are the success metrics that indicate you’re achieving your internal goals for the project?
Messaging: What’s the product messaging marketing will use to describe this product to customers, both new and existing?
Timeline/Release Planning: What’s the overall schedule you’re working towards?
Personas: Who are the target personas for this product, and which is the key persona?
User Scenarios: These are full stories about how various personas will use the product in context.
User Stories/Features/Requirements: These are the distinct, prioritized features along with a short explanation as to why this feature is important.
Features Out: What have you explicitly decided not to do and why
Designs: Include any needed early sketches, and throughout the project, link to the actual designs once they’re available.
Open Issues: What factors do you still need to figure out?
Q&A: What are common questions about the product along with the answers you’ve decided? This is a good place to note key decisions.
Other Considerations: This is a catch-all for anything else, such as if you make a key decision to remove or add to the project’s scope.


Revision bump for icu4c 72.1

Build PHP with revision bump for icu4c 72.1

:beers: @BrewTestBot has triggered a merge.

:beers: @BrewTestBot has triggered a merge.

:warning: @shivammathur bottle publish failed.

:beers: @BrewTestBot has triggered a merge.

:warning: @shivammathur bottle publish failed.


Upload not working after Back button

I can't get Croppie to work after I've submitted my image and pressed the back button. It submits to a new page, with the cropped image, but when I click on the browser Back button and try to Upload an image, it doesn't load into the preview frame. Any help is appreciated.

This doesn't sound like an issue related to croppie, but if you'd like someone to look at it, can you provide more info?  Maybe a link or a video demonstrating the issue?  Definitely would need some code at the very least.

Here is a video of what is happening. After I submit the crop, it goes to the next page, showing the cropped face on the elf body. When I click the Back button and try to upload another file. It doesn't load into the viewport.
https://www.youtube.com/watch?v=a4v0DebjsLY

<script type="text/javascript">
$( document ).ready(function() {

    var $uploadCrop;

    function readFile(input) {
        if (input.files && input.files[0]) {
            var reader = new FileReader();
            reader.onload = function (e) {
                $uploadCrop.croppie('bind', {
                    url: e.target.result
                });
                $('.upload-demo').addClass('ready');
            }
            reader.readAsDataURL(input.files[0]);
        }
    }

    $uploadCrop = $('#upload-demo').croppie({
        viewport: {
            width: 150,
            height: 200,
            type: 'circle'
        },
        boundary: {
            width: 300,
            height: 300
        }
    });

    $('#file-upload').on('change', function () { readFile(this); });
    $('.form_submit').on('click', function (ev) {
        $uploadCrop.croppie('result', {
            type: 'canvas',
            size: {width: 1000, height: 1000}
        }).then(function (resp) {
            $('#imagebase64').val(resp);
            $('#form').submit();
        });
return false;
    });

});
</script>

The only thing I can see off-the-bat is maybe your #file-upload isn't actually change'ing ... since you're picking the same image.  Try picking a different image?  If that works, try clearing the value of that field on page load if you really want users to be able to navigate that way.