readConcern.level Error

I'm trying to move from mongofill to this library. I've successfully build and added HHVM driver but keep getting this error.
Fatal error: Uncaught exception 'MongoDB\\Driver\\Exception\\RuntimeException' with message 'readConcern.level must be either 'local' or 'majority'' in /site/External/mongo-php-library/src/Operation/Find.php:179
Stack trace:
#0 /site/External/mongo-php-library/src/Operation/Find.php(179): MongoDB\\Driver\\Server->executeQuery()
#1 /site/External/mongo-php-library/src/Collection.php(439): MongoDB\\Operation\\Find->execute()
#2 /site/Service/Main.hh(7): MongoDB\\Collection->find()
#3 /site/Core/Main.hh(18): Service_Main::Packages()
#4 /site/Main.hh(18): Core_Main::initialize()
#5 {main}

I'm not sure how to set default readConcern.level. Any help would be appreciated.

You can set the default readConcern on a Client, Database or Collection by passing it in as one of the options like
$myClient->selectCollection("database", "collection", ["readConcern" => new MongoDB\Driver\ReadConcern(MongoDB\Driver\ReadConcern.LOCAL)])

LOCAL is the default on the Client if you don't explicitly specify, as far as I know, but I've been using the straight up PHP version (not HHVM). If the Manager class has an invalid readConcern by default, it sounds like a problem for https://github.com/mongodb/mongo-php-driver

@raeesiqbal: Are you explicitly setting the read concern in your own code?
Would you be able to provide a small stand-alone script that reproduces this error? Additionally, a var_dump() of your Collection object would be helpful, as that should report the read concern being used by the library. If you weren't specifying your own, we default to Manager::getReadConcern() (feel free to dump that as well).

When I try to set ReadConcern explicitly as suggested by @jacqueswaller. There is this error
Fatal error: Undefined constant 'MongoDB\\Driver\\ReadConcern' in /site/Core/Main.hh on line 11

Here is the output for get_declared_classes():
Array
(
    [0] => HH\Pair
    [1] => HH\Set
    [2] => HH\Vector
    [3] => Closure
    [4] => HH\ImmVector
    [5] => HH\ImmSet
    [6] => HH\ImmMap
    [7] => HH\Map
    [8] => MongoDB\BSON\Timestamp
    [9] => HH\Asio\WrappedException
    [10] => LazyFilterIterable
    [11] => DOMNodeIterator
    [12] => LazySkipKeyedIterable
    [13] => RecursiveFilterIterator
    [14] => LazyValuesIterator
    [15] => __SystemLib\TarArchiveHandler
    [16] => LazyFilterKeyedIterator
    [17] => MongoDB\Driver\Exception\LogicException
    [18] => NoRewindIterator
    [19] => XMLReader
    [20] => __SystemLib_ChunkedInflator
    [21] => HH\AsyncFunctionWaitHandle
    [22] => LazyFilterIterator
    [23] => IntlGregorianCalendar
    [24] => LazyZipIterator
    [25] => __SystemLib\DivisionByZeroError
    [26] => HH\WaitableWaitHandle
    [27] => MongoDB\Driver\ReadPreference
    [28] => AsyncMysqlErrorResult
    [29] => FilterIterator
    [30] => AsyncMysqlConnection
    [31] => ReflectionObject
    [32] => PDOStatement
    [33] => LazySkipWhileKeyedIterable
    [34] => BadMethodCallException
    [35] => SplObjectStorage
    [36] => SoapClient
    [37] => IntlDateFormatter
    [38] => LazyMapKeyedIterable
    [39] => MongoDB\Driver\Exception\WriteException
    [40] => MessageFormatter
    [41] => HH\AsyncGeneratorWaitHandle
    [42] => LazyKeysIterable
    [43] => HH\SleepWaitHandle
    [44] => SoapFault
    [45] => ReflectionExtension
    [46] => ReflectionProperty
    [47] => DateTimeImmutable
    [48] => HH\GenMapWaitHandle
    [49] => SplDoublyLinkedList
    [50] => LazyTakeIterable
    [51] => AsyncMysqlResult
    [52] => __SystemLib\InvariantCallback
    [53] => finfo
    [54] => MemcacheSessionModule
    [55] => LazySkipWhileKeyedIterator
    [56] => __resource
    [57] => ReflectionTypeAlias
    [58] => RecursiveDirectoryIterator
    [59] => LazySkipWhileIterator
    [60] => LazyKVZipIterator
    [61] => SplMaxHeap
    [62] => HH\Asio\WrappedResult
    [63] => Phar
    [64] => LazySliceIterator
    [65] => MongoDB\Driver\CursorId
    [66] => __SystemLib\ArithmeticError
    [67] => UConverter
    [68] => LazyIterableView
    [69] => PharException
    [70] => Memcached
    [71] => MongoDB\Driver\Exception\BulkWriteException
    [72] => DOMProcessingInstruction
    [73] => __SystemLib\ConvertIconvFilter
    [74] => LazyFilterWithKeyIterable
    [75] => AsyncMysqlConnectionPool
    [76] => SplMinHeap
    [77] => LazyMapWithKeyIterable
    [78] => LazySliceIterable
    [79] => __SystemLib\DeflateStreamFilter
    [80] => InvalidOperationException
    [81] => SQLite3
    [82] => __SystemLib\ParseError
    [83] => SpoofChecker
    [84] => mysqli
    [85] => HH\GenArrayWaitHandle
    [86] => DatePeriod
    [87] => ErrorException
    [88] => LazyValuesIterable
    [89] => InvalidArgumentException
    [90] => ReflectionFunction
    [91] => HH\Client\TypecheckResult
    [92] => Memcache
    [93] => __SystemLib\StringRot13StreamFilter
    [94] => LazyConcatIterator
    [95] => MongoDB\Driver\Exception\SSLConnectionException
    [96] => SplFixedArray
    [97] => DOMNodeList
    [98] => LazyTakeWhileIterator
    [99] => MongoDB\BSON\Regex
    [100] => RuntimeException
    [101] => FilesystemIterator
    [102] => ReflectionParameter
    [103] => __SystemLib\StreamFilterBucket
    [104] => MongoDB\Driver\Manager
    [105] => DateTime
    [106] => Redis
    [107] => MongoDB\Driver\BulkWrite
    [108] => LazyTakeWhileKeyedIterable
    [109] => RedisException
    [110] => AsyncMysqlRowBlockIterator
    [111] => LazyTakeWhileIterable
    [112] => AsyncMysqlQueryErrorResult
    [113] => SessionHandler
    [114] => DateInterval
    [115] => DOMNode
    [116] => AsyncMysqlException
    [117] => LazyTakeKeyedIterator
    [118] => IntlPartsIterator
    [119] => SplFileInfo
    [120] => DOMXPath
    [121] => AsyncMysqlQueryException
    [122] => LazyZipKeyedIterable
    [123] => Normalizer
    [124] => LazySkipIterable
    [125] => SQLite3Stmt
    [126] => SQLite3Result
    [127] => ReflectionFunctionAbstract
    [128] => DOMElement
    [129] => ZipArchive
    [130] => HH\AsyncGenerator
    [131] => mysqli_stmt
    [132] => mysqli_result
    [133] => DomainException
    [134] => __SystemLib\Error
    [135] => mysqli_driver
    [136] => ArrayIterator
    [137] => RecursiveCallbackFilterIterator
    [138] => AsyncMysqlConnectResult
    [139] => MongoDB\Driver\Exception\AuthenticationException
    [140] => LazyMapKeyedIterator
    [141] => AppendIterator
    [142] => LazySliceKeyedIterator
    [143] => DOMImplementation
    [144] => DOMException
    [145] => RegexIterator
    [146] => PDOException
    [147] => SoapParam
    [148] => EncodingDetector
    [149] => HH\RescheduleWaitHandle
    [150] => SplHeap
    [151] => DOMNotation
    [152] => MongoDB\BSON\MaxKey
    [153] => SplFileObject
    [154] => LazyMapIterator
    [155] => RangeException
    [156] => MongoDB\Driver\Exception\InvalidArgumentException
    [157] => LogicException
    [158] => __SystemLib\StringToUpperStreamFilter
    [159] => AsyncMysqlQueryResult
    [160] => DOMCdataSection
    [161] => HH\InvariantException
    [162] => LazyKeyedIterableView
    [163] => IntervalTimer
    [164] => MongoDB\Driver\Exception\ConnectionException
    [165] => RecursiveArrayIterator
    [166] => DOMAttr
    [167] => Imagick
    [168] => DOMNameSpaceNode
    [169] => HH\WaitHandle
    [170] => GMP
    [171] => OverflowException
    [172] => MemcachedSessionModule
    [173] => LazyMapIterable
    [174] => MapIterator
    [175] => LazyZipIterable
    [176] => ParentIterator
    [177] => XMLWriter
    [178] => DirectoryIterator
    [179] => ImagickDrawException
    [180] => HH\TypeStructureKind
    [181] => MongoDB\Driver\WriteConcernError
    [182] => Locale
    [183] => LazySkipIterator
    [184] => MongoDB\Driver\Exception\UnexpectedValueException
    [185] => ReflectionTypeConstant
    [186] => LazyFilterWithKeyIterator
    [187] => DOMEntityReference
    [188] => LazyKeysIterator
    [189] => SoapServer
    [190] => SimpleXMLElement
    [191] => ImagickDraw
    [192] => __SystemLib\MethCallerHelper
    [193] => IntlChar
    [194] => php_user_filter
    [195] => GlobIterator
    [196] => AsyncMysqlConnectException
    [197] => DOMEntity
    [198] => DOMNamedNodeMap
    [199] => AsyncMysqlClient
    [200] => LazySkipKeyedIterator
    [201] => __pinitSentinel
    [202] => SoapVar
    [203] => LengthException
    [204] => LazySkipWhileIterable
    [205] => MongoDB\Driver\Cursor
    [206] => Directory
    [207] => RecursiveCachingIterator
    [208] => MongoDB\Driver\WriteConcern
    [209] => RecursiveTreeIterator
    [210] => SoapHeader
    [211] => OutOfRangeException
    [212] => MCRouterException
    [213] => CallbackFilterIterator
    [214] => Transliterator
    [215] => ImagickPixelException
    [216] => LazyMapWithKeyIterator
    [217] => SplPriorityQueue
    [218] => IntlDatePatternGenerator
    [219] => UnexpectedValueException
    [220] => HH\ExternalThreadEventWaitHandle
    [221] => MongoDB\Driver\Server
    [222] => OutOfBoundsException
    [223] => Exception
    [224] => RedisSessionModule
    [225] => LazyConcatIterable
    [226] => UnderflowException
    [227] => BadFunctionCallException
    [228] => MCRouterOptionException
    [229] => mysqli_warning
    [230] => SimpleXMLIterator
    [231] => DOMText
    [232] => MongoDB\Driver\Query
    [233] => MongoDB\Driver\WriteError
    [234] => __SystemLib\AssertionError
    [235] => MongoDB\Driver\Command
    [236] => MongoDB\BSON\Javascript
    [237] => ImagickPixel
    [238] => IntlCodePointBreakIterator
    [239] => __SystemLib\InflateStreamFilter
    [240] => LazyTakeWhileKeyedIterator
    [241] => EncodingMatch
    [242] => AsyncMysqlClientStats
    [243] => Reflection
    [244] => HH\GenVectorWaitHandle
    [245] => SplTempFileObject
    [246] => MongoDB\Driver\Exception\ExecutionTimeoutException
    [247] => LazyTakeKeyedIterable
    [248] => ImagickException
    [249] => HH\BuiltinEnum
    [250] => MultipleIterator
    [251] => SplQueue
    [252] => APCIterator
    [253] => EmptyIterator
    [254] => LazyZipKeyedIterator
    [255] => __SystemLib\HH\Client\CacheKeys
    [256] => DOMDocumentFragment
    [257] => MongoDB\BSON\ObjectID
    [258] => __SystemLib\ArchiveEntryStat
    [259] => XhprofFrame
    [260] => SetIterator
    [261] => RecursiveRegexIterator
    [262] => AsyncMysqlRow
    [263] => IntlTimeZone
    [264] => VectorIterator
    [265] => DOMCharacterData
    [266] => CachingIterator
    [267] => DateTimeZone
    [268] => DOMComment
    [269] => SplStack
    [270] => stdClass
    [271] => DOMDocument
    [272] => LazySliceKeyedIterable
    [273] => AsyncMysqlRowIterator
    [274] => MongoDB\Driver\ReadConcern
    [275] => Collator
    [276] => HH\Client\TypecheckStatus
    [277] => HH\Shapes
    [278] => MongoDB\Driver\Exception\RuntimeException
    [279] => HH\ConditionWaitHandle
    [280] => ImagickPixelIterator
    [281] => MongoDB\BSON\Binary
    [282] => ReflectionClass
    [283] => ReflectionType
    [284] => PharData
    [285] => LibXMLError
    [286] => IntlCalendar
    [287] => LazyTakeIterator
    [288] => _SplPriorityQueueHeap
    [289] => HH\ResumableWaitHandle
    [290] => IntlRuleBasedBreakIterator
    [291] => MongoDB\BSON\UTCDateTime
    [292] => AsyncMysqlRowBlock
    [293] => DOMDocumentType
    [294] => NumberFormatter
    [295] => __SystemLib\StringToLowerStreamFilter
    [296] => MongoDB\Driver\Exception\ConnectionTimeoutException
    [297] => _SplDoublyLinkedListNode
    [298] => MongoDB\Driver\WriteResult
    [299] => ResourceBundle
    [300] => SimpleXMLElementIterator
    [301] => MongoDB\Driver\Utils
    [302] => PDO
    [303] => IteratorIterator
    [304] => RecursiveIteratorIterator
    [305] => LazyKVZipIterable
    [306] => InfiniteIterator
    [307] => MCRouter
    [308] => __PHP_Incomplete_Class
    [309] => MongoDB\BSON\MinKey
    [310] => PharFileInfo
    [311] => XSLTProcessor
    [312] => CURLFile
    [313] => Generator
    [314] => PairIterator
    [315] => ImagickPixelIteratorException
    [316] => __SystemLib\TypeError
    [317] => HH\AwaitAllWaitHandle
    [318] => ReflectionException
    [319] => IntlBreakIterator
    [320] => LazyFilterKeyedIterable
    [321] => __SystemLib\SessionForwardingHandler
    [322] => IntlIterator
    [323] => LimitIterator
    [324] => ReflectionMethod
    [325] => HH\StaticWaitHandle
    [326] => MySSLContextProvider
    [327] => MemcachedException
    [328] => ArrayObject
    [329] => __SystemLib\ZipArchiveHandler
    [330] => __SystemLib\ArchiveHandler
    [331] => ConfigSite
    [332] => StringBuilder
    [333] => VultrApp
    [334] => Page
    [335] => XHPChildrenDeclarationType
    [336] => xhp_link
    [337] => XHPAttributeType
    [338] => Scope
    [339] => xhp_s__img
    [340] => ServiceHostingType
    [341] => Core_H
    [342] => UserStatus
    [343] => APIException
    [344] => RedisObserver
    [345] => xhp_s__link
    [346] => ReflectionXHPChildrenExpression
    [347] => StringTemplates
    [348] => APIFieldException
    [349] => xhp_page_style
    [350] => xhp_x__composable_element
    [351] => ReflectionXHPAttribute
    [352] => Debug
    [353] => APIDeniedException
    [354] => CloudFlareSecurityLevel
    [355] => Mirror
    [356] => XHPChildrenConstraintType
    [357] => xhp_string
    [358] => ServiceDomainType
    [359] => VultrPlan
    [360] => xhp_xhp__html_element
    [361] => APIMultiException
    [362] => xhp_a
    [363] => xhp_google_captcha
    [364] => xhp_xhp
    [365] => CloudFlarePlan
    [366] => xhp_meta
    [367] => Theme
    [368] => Form
    [369] => xhp_page_head
    [370] => FormFieldType
    [371] => xhp_img
    [372] => xhp_s__a
    [373] => HostingStatus
    [374] => L_U
    [375] => OrderType
    [376] => APIAuthRequired
    [377] => HG_HostingOp
    [378] => SupportTicketStatus
    [379] => DiscountType
    [380] => xhp_hg__header__cart
    [381] => Core_Main
    [382] => xhp_page_footer
    [383] => TOTP
    [384] => xhp_x__element
    [385] => D
    [386] => xhp_page_script
    [387] => VultrDC
    [388] => xhp_s__meta
    [389] => DNSRecordType
    [390] => XHPChildrenExpressionType
    [391] => HTTP
    [392] => HG_DomainOp
    [393] => xhp_x__primitive
    [394] => DiscountProduct
    [395] => CloudFlareStatus
    [396] => ConfigRedis
    [397] => InvoiceStatus
    [398] => xhp_page
    [399] => RouterException
    [400] => xhp_xhp__html_singleton
    [401] => ReflectionXHPChildrenDeclaration
    [402] => HTTPException
    [403] => DomainStatus
    [404] => xhp_hg__dropdown
    [405] => CloudFlareTTL
    [406] => xhp_riot_element
    [407] => MongoDB
)

get_class_methods('MongoDB'):

Array
(
    [0] => __construct
    [1] => __get
    [2] => _getClient
    [3] => selectCollection
    [4] => _getFullCollectionName
    [5] => drop
    [6] => command
    [7] => getCollectionNames
    [8] => listCollections
    [9] => getIndexesCollection
    [10] => getGridFS
    [11] => authenticate
    [12] => createCollection
    [13] => createDBRef
    [14] => dropCollection
    [15] => execute
    [16] => forceError
    [17] => getDBRef
    [18] => getProfilingLevel
    [19] => getReadPreference
    [20] => getSlaveOkay
    [21] => lastError
    [22] => prevError
    [23] => repair
    [24] => resetError
    [25] => setProfilingLevel
    [26] => setReadPreference
    [27] => setSgetGridFSlaveOkay
    [28] => __toString
)

get_class_methods('MongoDB\Driver\ReadConcern'):
Array
(
    [0] => __construct
    [1] => getLevel
    [2] => __debugInfo
)

If I do
$client = new MongoDB\Client();
var_dump(MongoDB\Driver\Manager\getReadConcern());

It says, Fatal error: Call to undefined function MongoDB\\Driver\\Manager\\getReadConcern() in /site/Core/Main.hh on line 16

Here is the dump for
$reflection = new ReflectionClass('MongoDB\Driver\Manager')
var_dump($reflection->getMethods());

array(11) {
  [0]=>
  object(ReflectionMethod)#24 (2) {
    ["name"]=>
    string(11) "__construct"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [1]=>
  object(ReflectionMethod)#25 (2) {
    ["name"]=>
    string(11) "__debugInfo"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [2]=>
  object(ReflectionMethod)#26 (2) {
    ["name"]=>
    string(14) "executeCommand"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [3]=>
  object(ReflectionMethod)#27 (2) {
    ["name"]=>
    string(12) "executeQuery"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [4]=>
  object(ReflectionMethod)#28 (2) {
    ["name"]=>
    string(16) "executeBulkWrite"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [5]=>
  object(ReflectionMethod)#29 (2) {
    ["name"]=>
    string(10) "getServers"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [6]=>
  object(ReflectionMethod)#30 (2) {
    ["name"]=>
    string(14) "getReadConcern"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [7]=>
  object(ReflectionMethod)#31 (2) {
    ["name"]=>
    string(17) "getReadPreference"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [8]=>
  object(ReflectionMethod)#32 (2) {
    ["name"]=>
    string(15) "getWriteConcern"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [9]=>
  object(ReflectionMethod)#33 (2) {
    ["name"]=>
    string(8) "__wakeUp"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
  [10]=>
  object(ReflectionMethod)#34 (2) {
    ["name"]=>
    string(12) "selectServer"
    ["class"]=>
    string(22) "MongoDB\Driver\Manager"
  }
}

I'll try to reproduce it in a bare minimum environment soon.

@raeesiqbal: I'm not sure why you dumped get_class_methods('MongoDB') above, as that's a class from the legacy driver (also present in mongofill) and not related to this library or the current HHVM extension.

If I do
$client = new MongoDB\Client();
var_dump(MongoDB\Driver\Manager\getReadConcern());

It says, Fatal error: Call to undefined function MongoDB\Driver\Manager\getReadConcern() in /site/Core/Main.hh on line 16

An error makes sense in this case, as MongoDB\Driver\Manager\getReadConcern() is syntax for a getReadConcern() function within the MongoDB\Driver\Manager namespace. My suggestion was the poke inside the Collection object (or capture the array returned by __debugInfo()) and dump the manager's read concern with something like:
$debug = $collection->__debugInfo();
var_dump($debug['manager']->getReadConcern());

Okay, here is my minimum repro environment.
/var/www/mongo-test
                                     main.hh
                                     External/
                                                    mongo-php-library/
                                                    app.hdf
                                                    mongodb.so
                                                    require.php

main.hh
<?php
spl_autoload_register(function($Name){
  // MongoDB Driver for HHVM
  if(substr($Name, 0, 7) !== 'MongoDB') return;
  $Path = __DIR__.'/mongo-php-library/src/'.str_replace("\\", '/', substr($Name, 8)).'.php';
  if(file_exists($Path)){
    require($Path);
  }
});

app.hdf
Server {
    Host = mongo-test
    IP = <IP_ADDRESS>
    Port = 80

    SourceRoot = /var/www/mongo-test

    RequestTimeoutSeconds = 512
    RequestMemoryMaxBytes = 16777216

    DefaultDocument = main.hh
    ErrorDocument404 = main.hh

    FatalErrorMessage = There was a problem in website loading. Please wait a few moments and refresh.

}
Hack {
  Lang {
    LookForTypechecker = false
  }
}
DynamicExtensions {
  mongodb = /var/www/mongo-test/External/mongodb.so
}

As funny as it is, I tried this and it worked.
$DB = (new MongoDB\Client())->selectDatabase('mongodb', ["readConcern" => new MongoDB\Driver\ReadConcern('local')]);

This may have been related to HHVM-175.


xdg-shell: don't destroy xdg role state on role destroy

ie. don't destroy surface->toplevel on xdg_toplevel destroy. Instead do this on
xdg_surface destroy.
This allows compositors to add toplevel listeners when the surface appears and
remove them when the surface is destroyed.
This fixes part of @Timidger's segfaults:
==25315== Invalid write of size 8
==25315==    at 0x490344B: wl_list_remove (wayland-util.c:56)
==25315==    by 0x122FC7: destroy (xdg_shell.c:267)
==25315==    by 0x114806: view_destroy (desktop.c:448)
==25315==    by 0x123516: handle_destroy (xdg_shell.c:396)
==25315==    by 0x48C175F: wlr_signal_emit_safe (signal.c:29)
==25315==    by 0x48A1647: destroy_xdg_surface (wlr_xdg_surface.c:459)
==25315==    by 0x48A011C: xdg_client_handle_resource_destroy (wlr_xdg_shell.c:71)
==25315==    by 0x48FF17D: destroy_resource (wayland-server.c:688)
==25315==    by 0x49033F1: for_each_helper.isra.0 (wayland-util.c:372)
==25315==    by 0x49038DE: wl_map_for_each (wayland-util.c:385)
==25315==    by 0x48FF2DC: wl_client_destroy (wayland-server.c:847)
==25315==    by 0x48FF3B4: destroy_client_with_error (wayland-server.c:307)
==25315==    by 0x48FF3B4: wl_client_connection_data (wayland-server.c:330)
==25315==  Address 0xbf50310 is 160 bytes inside a block of size 288 free'd
==25315==    at 0x48389AB: free (vg_replace_malloc.c:530)
==25315==    by 0x48A0A05: destroy_xdg_toplevel (wlr_xdg_surface.c:91)
==25315==    by 0x48A2E57: xdg_toplevel_handle_resource_destroy (wlr_xdg_toplevel.c:448)
==25315==    by 0x48FF17D: destroy_resource (wayland-server.c:688)
==25315==    by 0x48FF1DD: wl_resource_destroy (wayland-server.c:705)
==25315==    by 0x48A2E25: xdg_toplevel_handle_destroy (wlr_xdg_toplevel.c:424)
==25315==    by 0x66561C7: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
==25315==    by 0x6655C29: ffi_call (in /usr/lib/libffi.so.6.0.4)
==25315==    by 0x4902AEC: wl_closure_invoke (connection.c:1006)
==25315==    by 0x48FF568: wl_client_connection_data (wayland-server.c:420)
==25315==    by 0x4900B31: wl_event_loop_dispatch (event-loop.c:641)
==25315==    by 0x48FF759: wl_display_run (wayland-server.c:1260)
==25315==  Block was alloc'd at
==25315==    at 0x4839B65: calloc (vg_replace_malloc.c:752)
==25315==    by 0x48A2EAC: create_xdg_toplevel (wlr_xdg_toplevel.c:465)
==25315==    by 0x48A0F01: xdg_surface_handle_get_toplevel (wlr_xdg_surface.c:251)
==25315==    by 0x66561C7: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
==25315==    by 0x6655C29: ffi_call (in /usr/lib/libffi.so.6.0.4)
==25315==    by 0x4902AEC: wl_closure_invoke (connection.c:1006)
==25315==    by 0x48FF568: wl_client_connection_data (wayland-server.c:420)
==25315==    by 0x4900B31: wl_event_loop_dispatch (event-loop.c:641)
==25315==    by 0x48FF759: wl_display_run (wayland-server.c:1260)
==25315== by 0x119E4A: main (main.c:74)

Thanks!


setState warnings, Broken Images, & Race Conditions

This PR potentially resolves:

https://github.com/jayesbe/react-native-cacheable-image/issues/22 (setState warning)
https://github.com/jayesbe/react-native-cacheable-image/issues/27 (Broken cached image)

Summary of fixes:

Resolves all instances of setState warnings.
Solves an issue where an image that is being downloaded in a different component displays as blank space.
Solves an issue where downloads were being restarted after every parent update.
Fixed a bunch of race conditions related to networking and the delay between javascript & native code.

There is also a possibility that if you render many images that need to be downloaded, and then cause the jobs to be cancelled (for example, by navigating to a different screen), you may get an error from React Native of the form "Callback with id #: undefined.undefined() not found". This is caused by RNFS itself and I have a PR set up here: https://github.com/johanneslumpe/react-native-fs/pull/219
Here is a walkthrough of the code changes:

Merged in @jayesbe’s changes in the comments of Issue #22 (setState warning), with some help from @robwalkerco.

downloading and jobId are not used in the render functions, and a race condition can cause these to be out of date when using this.setState() because it is asynchronous. These have been moved out of the state object.

_processSource() was erroneously triggering a re-download even when the source URI was identical. Any re-renders in the parent component, or change in network state, were causing the download to be restarted. Comparing the URI property (when present) saves us from accidentally downloading the same image twice.

I have re-added a file size check in checkImageCache(). This is necessary because on iOS, RNFS creates a zero-byte file when it begins the download. In my application, sometimes a component uses the same URI as another CacheableImage instance. There was a situation where the first component began downloading, and the second one saw the empty file and displayed a blank image. React Native does not update the image when it is changed on disk, so it rendered as transparent.
The file size check throws an error if there is a zero-byte file, whether it is still downloading or sometime else caused the download operation to not complete. The error starts a new download.

An alternative to this functionality could be to first download the image to a random temporary location until it is completed downloading, but you still might find a race condition while the file is being moved to the final location. Also, that alternative could still result in two downloads of the same image.
Ideally, RNFS would check to see if it is already downloading a URI, and bind the two jobs into one. But I think this is an edge case overall.

Fixed a typo in RNFS.mkdir().then() (_deleteFilePath())

Added a check to stop an in-progress download before starting a new one in the same component.

RNFS.downloadFile() immediately returns the jobId, so I captured that synchronously. Without this, a race condition exists where the component might unmount before imageDownloadBegin() is called, and thus won’t cancel the download job. This can cause a setState warning, not to mention a waste of bandwidth.

Because RNFS throws an error when you call stopDownload(), I added a check in the error handler to avoid a setState warning. (We only call stopDownload() on unmount) It is still necessary to call _deleteFilePath() on an error or cancelled download, because RNFS does not remove a partially-downloaded file when this happens.

_handleConnectivityChange() is now unset in componentWillUnmount(), and its status is checked in the initial NetInfo fetch. This solves an issue where a component will quickly mount and then unmount before the initial fetch is resolved. Without this, you may see setState warnings especially if you use local images and accidentally keep props.checkNetwork == true.

@nbolender Nice work. I've started using your this branch in my project, and it is a big improvement, but there still seems to be something causing a setState warning.
I'm not sure how to figure out where the warning is being triggered though. Any tips on tracing the exact bit of code?

@robwalkerco I believe there is still one possibility for a setState warning in the downloadFile completion handler (downloadFile().then()). This could occur if the download completes some time after the component unmounts, so the completion handler is called.
If you can reproduce it consistently, you might try commenting out the setState statement in the completion handler to see if it is in there.
If that's indeed the issue, it might be best to drop the imageDownloadProgress callback altogether, then perform the same check in the download completion handler as we do in its error handler.

@nbolender  great work. This is very much appreciated. I will go through this soon and Im sure it will be merged by the end of the week.

@nbolender I've isolated the warning to the setState in RNFS.stat().then() https://github.com/jayesbe/react-native-cacheable-image/pull/33/files#diff-a55ceb1e7b521b129b05093109b0da5bR64
I'll try to figure out more tomorrow, but it seems to happen when you first mount a page containing cachable images, then unmount, then mount the same page again. The images are displayed fine, but the warning occurs.

@nbolender I've not managed to figure out the exact cause of warning for me yet, and why it consistently occurs
I have managed to prevent setState from giving any warnings by wrapping each setState in
if (this.mounted) {
    setState...
}

and using componentWillMount and componentWillUnmount to set the boolean, though I think that's an anti-pattern in this case (https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html)

Any news about merging this one?

I've stopped using this package now, as I was still having issues that were only fixed by my hacky work around :(
This PR was an improvement though, so I think it would be helpful if merged.

Sorry guys have been a little behind. Please create new issues if / when they come up :)

Hm @robwalkerco tested your PR having the same issues as before. Had to switch to https://github.com/kfiroo/react-native-cached-image :-(


feat: update Prisma schema

Description
referentialIntegrity = "prisma" is deprecated, the latest feature is relationMode = "prisma".
Also since "referentialIntegrity" is deprecated, preview feature functionality can be used without specifying it.
Testing Instructions
Didn't do any testing steps, i just saw this warning as i'm setting up my own monorepo and decided to update your example aswell. (should not mess anything up, based on https://pris.ly/d/relation-mode)

Allow CI Workflow Run

[ ] approve CI run for commit: bb3c3ed3e8aa30a9967c170afd8c6b916951bbab

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

No worries, i also believe i have a slightly better version of the client.ts but im not sure. will soon make a PR with it to see what u guys think


updating dependecies to support svelte 4

Thanks for the PR!
Unfortunately it's bit more complicated.
I have adjust the packaging as well to be compatible with @sveltejs/package v2.
Also need to update the whole exporting to be compatible with the older moduleResolution, because of the new moduleResolution.
I need few days, since I'm not home yet. But on the weekend, I hope it will be done.


Documentation - improve instructions for adding the stand-alone add-in to ArcMap

Currently, there is a gap in instructions between adding the add-in to ArcMap and instructions explaining functionality. We need to add these instructions to the documentation for distance and direction, as the add-in doesn't automatically get added to the toolbar.
These are the instructions for Coordinate Conversion. They are identical for what we need for Distance and Direction:
Click Customize Mode under Customize menu
Customize window appears.
Select the Commands tab
Select Add-In Controls from Categories
Drag and drop Coordinate Conversion tool from Commands onto an existing toolbar
Close the Customize window

related to https://github.com/Esri/visibility-addin-dotnet/issues/180 @dfoll fyi

Verified that this has been published to Solutions:

Ready to close.
@dfoll  @ACueva

This is not done because we need to create this in CMS.

@ACueva @topowright @BobBooth this is ready to verify on DEV.


Issue connecting to Btc-rpc, RTL, & Electrum RS

I have my node set up and I downloaded btc-rpc explorer, RTL web node manager, Electrum Rust Server, etc.. But, when I try to scan the QR code it doesn't allow me to visit the website. I get an error message.
Unable to connect:
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your device’s data or Wi-Fi connection.
This happens on all web browsers.

Try restarting the node.
Test nginx with:
sudo nginx -t

@Shampow8 Close this pls if solved.


[FEA] Rename --benchmark-gpu-disable

How do y'all feel about changing --benchmark-gpu-disable to something like --benchmark-gpu-nomemory or --benchmark-gpu-nomemtest or --benchmark-gpu-skipmem ?
The current name seems a little misleading. It's not disabling the GPU, but just a set of metrics.
@awthomp

@mnicely, no issues here. I'll coordinate the update with @dillon-cullinan. This is low priority though, so no ETA at the moment.


Componenet -> Component

Pull Request Test Coverage Report for Build 308296668

2 of 2 (100.0%)  changed or added relevant lines in 2 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.007%) to 39.514%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/common/ports.ts
4
74.14%

Totals

Change from base Build 307497149:
-0.007%

Covered Lines:
20213

Relevant Lines:
46860

💛  - Coveralls


Running Time and Other Questions

@fkodom this is great work!!! :smile:   I'm very interested in trying out what you've built. I'm hoping that you could answer some of my questions.  I saw that you were using a GTX 2080 for the GPU, what were it's memory limits? Based on your ability to process 32M Context Tokens, can you extrapolate how much memory would be required for the full 1B Context Tokens? How long did it take to run? I'm trying to get an upfront idea of the costs involved with using this technique. Did you choose not to attempt distributed training based upon the fact that you only had 1 GPU available to you, or was there something particularly challenging with creating a Distributed version? Thank you in advance for taking the time to read this issue and your contributions to LLMs.

Hi, @MHarris021!  Trying to answer all of your questions above 😅

I saw that you were using a GTX 2080 for the GPU, what were it's memory limits?
It has 11 GB VRAM.

can you extrapolate how much memory would be required for the full 1B Context Tokens?
Complexity and memory footprint are $O(N d)$ where $N$ is the sequence length and $d$ is the hidden dimension.  So, as usual, the memory footprint is also dependent on model size.  But if 32M tokens require about 10 GB VARM, then 1B tokens would require roughly 310 GB VRAM -- hence the need for distributed computing.

^^ The authors aren't clear what hyperparameters (i.e. hidden dimension, number of heads) were used in their version of the 1B-token benchmark.  I suspect those parameters were very small, otherwise they would need quite a few A100 80GB GPUs just to pull off the benchmark.  But their point was to show it's feasible to scale to 1B tokens, not actually train a model with 1B context windows.

Did you choose not to attempt distributed training based upon the fact that you only had 1 GPU available to you, or was there something particularly challenging with creating a Distributed version?

So far, this is purely for cost reasons.  This is a side project, so I don't have a large compute budget. 😂 There's nothing inherently difficult about the distributed training -- libraries like huggingface/accelerate and Lightning-AI/lightning make distributed jobs fairly easy IMO.  Here's an example training script from another project, which uses lightning and is compatible with local or distributed training.
I was planning to write a similar script for LongNet.  But it would likely use a smaller toy dataset, so I can easily train without the cloud costs. 😂

@MHarris021 Interesting, I wasn't aware of kyegomez implementation.  I agree, a bit difficult to tell what's going on there.  Just from eyeing it over, I'm certain our two implementations are not equivalent.  Operations like these scale very badly on GPUs, and I think there are quite a few other, more fundamental differences.  They have definitely done a better job of socializing their implementation. 😂
What is your goal in trying to replicate the repo?  Aside from educational purposes, which is usually why I work on these things haha. 🙃

Training a 1B-parameter model with 1B context window would require an astronomical cloud budget. 😰
To confirm/verify my results, does it help to look at the benchmark script?
https://github.com/fkodom/dilated-attention-pytorch/blob/87cda7579874b6485ea81a742b6a0dc51ffad6cc/benchmark.py

@fkodom
yes, we were able to successfully verify your results.  we used an RTX A5000 w/ 24GB of VRam, took us about 10 minutes once we got everything setup. We're now benchmarking against 64M tokens to see if it is handled by the 24 GB of Vram on the GPU.

64 Million tokens were processed successfully! runtimes increased by a factor of 2, if i modified the benchmark correctly.
Now, processing in parallel (multiple GPUs) will need to be tested.

@MHarris021 good to hear 👍

@fkodom
We've been able to expand to 288 Million (1.125x 2**28) tokens on a single NVidia A100 (80GB VRam) on Runpod. This is the maximum number of tokens that seem to fit into the gpu memory. We are noticing a significant increase in the base processing time every time the number of tokens doubles. The note that you made about the smaller dilated sequence lengths taking longer to process also becomes more pronounced. I'm assuming that this is expected based upon the processing time per token. We estimate that we would need to distribute the benchmarking to 4 A100's (320GB of VRam) in order to process the 1 Billion context tokens. This was inline with your previous prediction. I suspect that the distributed processing will stay similar to the 288 Million tokens as the processing should proceed in parallel, so even though the token count will go up by 4x the total time should stay constant as 4 GPU's will be processing in parallel. There may be some increases due to coordination overhead. This also suggests that we may be able to get similar results by using 8 GPU's each with 40GB of VRam and that GPU Memory may be the primary bottleneck.
Benchmarking data follows:

@MHarris021 Closing this issue for now.  Feel free to open another, if you have questions about a particular part of the code.


envoy: Pass NACK notifications to XDSServer

Let XDSServer know about NACKs so that it can retry with an updated
configuration. This version simply retries with the same configuration
up to 10 times before giving up. This may help resolve NACKs that are
caused by rare timing issues.
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>

This change is

test-me-please

test-me-please

@rlenglet Changed the approach as you requested. Please have another look.

Fixed a unit test failure, added server e2e test.

test-me-please

Fixed format

test-me-please

test-me-please

@rlenglet Added the actual proxy port reallocation, as we do not pass a force flag through the Upserts(), meaning that an unmodified resource would simply not modify the cache. Please have another look!

Changing the test fail condition might be premature, as it would be good to catch a run that successfully retries a NACK.

test-me-please

test-me-please

test-me-please

@rlenglet CI passed & I have addressed your concerns. Potentially may need to squash the commits and reconsider under which conditions we want to fail CI based on NACKs appearing in logs.

@rlenglet Typically a new proxy is created before the bpf is compiled, basically the bpf program compilation is waiting for the the ACK for the proxy configuration, so it might be possible to not require re-compilation if we can update the allocated port in Endpoint's config that is then used for the bpf generation?

Yes, that's the idea. Unfortunately, the desiredRedirects map that contains the allocated redirect ports is only a local variable in regenerateBPF. You need to somehow get to modify the ports in that local variable map before its values are used.

test-me-please

test-me-please

test-me-please

Retrying and reallocating from the nack callbacks turned out to be error prone due to locking order differences between the normal code paths vs. paths leading to and via the callbacks. I simplified the approach here by removing the retry attempts, but returning from the Wait immediately if a NACK is received. This way we dont spend a minute waiting for nothing.
Going forward we can make sure that if endpoint regeration fails, the xDS resource changes made are rolled back so that we can try the whole regeneration again.

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please


Fixed ctrl+up/down shortcut no longer working in scene tree

Fixed ctrl+up/down shortcut no longer working in scene tree.
I'm not super happy with the way this was solved, if someone has a better idea please comment.
This fixes #7736
BTW the problem is related to #18793

Changed it to get_command instead of get_control

Thanks!


"Ruginoasa", "Ungureni", "Valea Uleiului" are listed in the drop-down menu

Description:
When user writes "Ruginoasa", "Ungureni" and "Valea Uleiului" the locations appear in the drop-down menu next to the comune and the county witch is a part according to the law
Precondition:
The website is up an running.

Step 1
Write in the search bar "Ruginoasa"

Expected results
The location appears in the drop-down menu as "Sat Ruginoasa, ARGEȘ (Valea Iașului)"

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Ungureni"

Expected results
The location appears in the drop-down menu as "Sat Ungureni, ARGEȘ (Valea Iașului)"

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Valea Uleiului"

Expected results
The location appears in the drop-down menu as "Sat Valea Uleiului, ARGEȘ (Valea Iașului)"


📝 add Chinese document

Fix for Issue #168
Description
I added the Chinese document for this project.

looks good. I may rework the config structure (but since vitepress is still in alpha it's ok). thanks a lot for the help and for the Chinese vue community!

looks good. I may rework the config structure (but since vitepress is still in alpha it's ok). thanks a lot for the help and for the Chinese vue community!

This is also my first time to participate in an open source project. Although it is only a translation, I am a little excited. I will continue to work hard to improve myself. 😀😀😀

looks good. I may rework the config structure (but since vitepress is still in alpha it's ok). thanks a lot for the help and for the Chinese vue community!

This is also my first time to participate in an open source project. Although it is only a translation, I am a little excited. I will continue to work hard to improve myself. 😀😀😀

Documentation is so important in projects. It is what helps people use the tool!
🎉 Congrats on your participation and thanks again for contributing :)


Only skip migration when version matches

Codecov Report

Merging #211 (19d6718) into develop (5648a0e) will increase coverage by 0.00%.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff            @@
##           develop     #211   +/-   ##
========================================
  Coverage    59.59%   59.60%
========================================
  Files           84       84
  Lines        15270    15268    -2
========================================
  Hits          9100     9100
+ Misses        6170     6168    -2

Impacted Files
Coverage Δ

src/abci/node.rs
0.00% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Automated performance validation test on device

To monitor the performance changes within MRTK3, it would be super useful to have a scene with associated scripts to perform some common operations on devices and give us performance numbers when the operations are done (e.g. 95 percentile fps, etc.) This way we can better understand how we are doing on perf and also catch performance regressions.

We have a different work stream looking at ways to monitor performance, separate from MRTK work.  However the goal is that we would monitor performance across Unity versions, OS versions, MRTK versions, OpenXR Runtime versions, and OpenXR MR Plugin versions


What is expected behavior of AbortTestRun and CancelTestRun?

Description
We've implemented an IVsTestConsoleWrapper and are have ITestRunEventsHandler that monitors test execution. When running multiple iterations of a same test to gather performance data and the test is failing, we want to fail fast, rather than waste time continuing to run a test that is not yielding useful information (beyond the fact that something is broken).
Steps to reproduce
Call VsTestConsoleWrapper.RunTests(testCases, runSettings, options, testRunEventsHandler);
testCases is an enumerable list of a single test case to run for several iterations (e.g., 12)
runSettings is valid runsettings XML, including 1 so testRunEvents are provided for every execution
testRunEventsHandler includes an implementation of HandleTestRunStatsChange that detects test failures and calls AbortTestRun when too many are seen.
Expected behavior
I would expect that once AbortTestRun is called, no further testCases in the list will be executed.
Actual behavior
All testCases are executed.
Diagnostic logs
In this log, the abort case is simulated by calling AbortTestRun on every call to HandleTestRunStatsChange after the third one.
diag2.log
Environment
Microsoft Windows [Version 10.0.19041.450]
Microsoft (R) Test Execution Command Line Tool Version 16.8.0-preview-20200812-03

@wiweinbe If you want immediately stop test run you can use wrapper.EndSession() - where wrapper is object of your VsTestConsoleWrapper

@Sanan07 That sounds like a really big hammer. But worth considering.

@wiweinbe After my quick investigation, I see that, AbortTestRun() calls asynchronously, so while aborting operation is executing, tests are running in another thread. AbortTestRun calls HandleTestRunComplete from ITestRunEventsHandler and complete execution.
I did my own test: using 300 empty test methods. I have condition: to abort after 10 test methods already executed, but it ended up aborting after 170 or 220 test method, during different runs.
I suppose, the same happens in your case : your tests are executing quite quickly, so they had finished before aborting started.
Try to increase number of tests and see if it aborts before all tests executed.

Hope, that helps to understand.

That is helpful. I've actually made progress on this and found that I get a more expected behavior by calling CancelTestRun, instead of Abort (and by operating on a more realistic test case that takes some time to execute).
However, it appears that even in this case, the run acts more like it's aborted. Much of the end processing (what you note as HandleTestRunComplete above?). For instance, our data collectors do not get notified of OnTestSessionEnd in order to do session-level cleanup. On one level, this seems like a bug.
Also, is there documentation for all of this behavior? I can't find any.

@wiweinbe When you call AbortTestRun it then calls HandleTestRunComplete, so you can collect your metadata as inside HandleTestRunComplete, but CancelTestRun just cancel active test run, so that why you can collect metrics.
As you can see from this comment BaseTestsRun.cs , when you call CancelTestRun it does not call HandleTestRunComple to cancel quickly.
I was not able to find any related docs either. We are planning to update and extend our documentation, so possibly we will add in future.


[WIP] feature: use can name data to identify source

The logic here keeps a map from srcs to data received for this source in PGN
60928. This data is used to add manufacturerCode and uniqueNumber fields to
each delta update's source object. If there is no 60928 can name data a
59904 PGN is sent to request the data from the source.
Deltas that do not have can name data for their src can optionally be
ignored by configuration option ignoreUnknownSrcs.
Furthermore  package.json references signalk-schema version
#canname, where the canname data is used to generate source paths.

If you wish to explore this make sure you are using the modified signalk-schema from specification repo. Simplest way to do that is to run npm install, which should install signalk-schema package from specification #canname branch.


dataset

Can you share the prepared dataset?

Code to prepare the dataset is in https://github.com/mitroadmaps/roadtracer/tree/master/dataset.
The prepared ground truth segmentation masks are available at https://roadmaps.csail.mit.edu/roadtracer/. The pre-trained model weights are also available there.
As we say there, the Google Maps imagery is copyrighted so we cannot redistribute it.


Support async functions for wasm_bindgen(start)

We currently support async functions in a variety of places, including in unit tests and in pub functions exposed to JS.
When writing applications, it's common to have a single "root" async function which kickstarts everything. Right now you have to do something like this:
async fn main_async() -> Result<(), JsValue> {
    // ...
}

#[wasm_bindgen(start)]
pub fn main_js() {
    spawn_local(async {
        main_async().await.unwrap_throw();
    });
}

But it would be great if we could instead do this:
#[wasm_bindgen(start)]
pub async fn main_js() -> Result<(), JsValue> {
    // ...
}

The semantics is that it would generate a new shim function which calls spawn_local and logs the Err.
It should support a return value of either () or Result<(), JsValue>.

I was surprised to find that:
#[wasm_bindgen(start)]
async fn main() { }

isn't supported.

@daxpedda It is supported, you have to do this:
#[wasm_bindgen(start)]
pub async fn main_js() { }

This is also supported:
#[wasm_bindgen(start)]
pub async fn main_js() -> Result<(), JsValue> { Ok(()) }

I mean specifically fn main, if you name it something else Rust will complain that you don't have a main function if you are making a binary.
Currently if you put #[wasm_bindgen(start)] on async fn main() it will complain that the main function can't be async. This is why other solutions out there like tokio or async_std remove the async and put their block_on inside, which wasm-bindgen could do too. Not sure of the limitations though.
See #3076.

wasm-bindgen does not support creating binaries, you must always create it as a lib. Binaries have a ton of extra code bloat, increasing the file size of your Wasm for no additional benefit.

wasm-bindgen does not support creating binaries, you must always create it as a lib.

I am a bit confused, what does that mean exactly? wasm-bindgen generates .wasm and .js files, none of these are binaries as far as I know. What I meant was letting Rust have a binary target, which still produces a .wasm file that can be used by wasm-bindgen. wasm-bindgen has support to detect the main function.

A wasm-bindgen app that uses #[wasm_bindgen(start)] is effectively a binary, even if it's being compiled as a lib.

I am aware of the size difference. There are tons of use-cases where they don't really matter. Personally I'm writing libraries and applications that are supposed to be as cross-platform as possible. In these cases these apps are so big that the bloat generated by having a binary target is something I don't really care about. I wish of course that the bloat could be removed, but sadly Cargo has limitations around this that prevent this from being easy.
Cross-platform examples is another case where it requires extra code and effort by the user to write those, because they do require a main function.
Basically what I'm saying is, I know this is a complete convenience thing, it's has disadvantages, but considering it should be quiet simple for wasm-bindgen to support this case, it's a benefit users would appreciate I believe.

What I meant was letting Rust have a binary target, which still produces a .wasm file that can be used by wasm-bindgen.

Yes, that's exactly what I mean. You should not be compiling your wasm-bindgen code as a bin, you should always be compiling it like this:
[lib]
crate-type = ["cdylib"]

If you use wasm-pack or the Rollup plugin (recommended) then it will always compile it as a lib, as intended.

Personally I'm writing libraries and applications that are supposed to be as cross-platform as possible.

In that case you should use cfg to select the right implementation based on the platform:
// lib.rs
#[cfg(feature = "wasm")]
#[wasm_bindgen]
pub async fn main_js() {
    ...
}

// main.rs
fn main() {
    ...
}

You already need to use cfg when creating cross-platform libraries or applications, because Wasm behaves very differently from native platforms, so you need Wasm-specific APIs.
With the above code, it will use main() for the non-Wasm code, and main_js() for the Wasm code. Both the main.rs and lib.rs can co-exist peacefully in the same crate.
And the main.rs file can import the things which are exported from lib.rs, so you won't have any code duplication. All of your code lives in lib.rs, and main.rs is just a tiny shim that calls the lib.rs code.

Minor correction. In order to have both a lib.rs and a main.rs at the same time, you have to specify this in your Cargo.toml:
[lib]
crate-type = ["lib", "cdylib"]

Now it will work correctly. Here is a zip file containing a working example which contains both Wasm and non-Wasm code:
cross-platform-example.zip
You can use cargo build or cargo run for the non-Wasm binary, and yarn build for the Wasm binary. This is the ideal idiomatic setup.
And as a bonus, because it's using Rollup you get a ton of useful features for free: you can easily import and use npm packages, it optimizes and bundles your JS code (making it optimal in performance and file size), you get a livereload server and watch mode for free, etc.

I know of these Rust-side solutions, what I'm trying to get at here is that there is some room for improvement that don't require additional workarounds.
Basically I'm trying to find a solution for Rust users that require zero additional work or reduce it to a minimum, it would be great if that has no overhead, but here we are.
I do believe that adding the ability to handle main is an additional convenience Rust users can benefit from, downsides should be documented and solutions should be offered.
In a perfect world we solve the fact that compiling binaries has overhead on the Rust side, that's something I didn't look into.
Thank you for your input anyway.

Basically I'm trying to find a solution for Rust users that require zero additional work or reduce it to a minimum, it would be great if that has no overhead, but here we are.

The zip file I gave you is the minimal amount of work. Compiling to Wasm requires a lot of things, simply compiling as a bin is not enough, additional setup is always required.
That's why the Rollup plugin automatically handles 99% of everything, so that it is as easy to use as possible.
It is as easy as doing yarn install and then yarn build, with everything taken care of automatically, similar to cargo build.
If you choose to not do that, then you'll have to manually build with the right flags, manually call wasm-bindgen with the right flags, download wasm-opt and call it with the right flags, handle inline_js in some way... it's a mess.
That's why we created things like the Rollup plugin, to make the process as easy as possible. It minimizes the amount of work that the user has to do, and it minimizes the amount of extra knowledge that the user needs.
wasm-bindgen was never intended to be used directly by users, it was always intended as a low-level tool which is used by higher-level tools. Think of wasm-bindgen as being similar to rustc, and the Rollup plugin as being similar to cargo.

I'm gonna try to be as clear as possible. Take your zip file. Try to add an example. You have to add this workaround:
#[wasm_bindgen(start)]
pub async fn real_main() {
    // your code goes here
}

fn main() { }

If #[wasm_bindgen(start)] would support async fn main() this workaround would not be needed. Clearly this workaround works and it's not a big deal. But additional support is still an improvement.

If you are creating a cross-platform application, then you will have to use async fn for both mains, which means you will need to choose an async library, so your code will be something like this:
// lib.rs
#[wasm_bindgen(start)]
pub async fn main_js() -> Result<(), JsValue> {
    call_init_function().await;
    Ok(())
}

// main.rs
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    call_init_function().await;
    Ok(())
}

And the code will be different if you're using async-std, etc.
This is not a "workaround", this is just how Rust works. You have two different mains, with different attributes, different types, different async runtimes. So it makes perfect sense that you will define it as two different functions.
If you don't define it as two functions, but as just one async fn main, then you wouldn't be able to choose the runtime (like tokio, or async-std, etc.) So it wouldn't work.
When creating cross-platform libraries or applications, it is completely normal to have two implementations: one for Wasm and a different one for everything else. For example:
#[cfg(feature = "wasm")]
pub fn foo() -> u32 {
    // Wasm implementation goes here
}

#[cfg(not(feature = "wasm"))]
pub fn foo() ->  u32 {
    // non-Wasm implementation goes here
}

This is not because of any limitation in wasm-bindgen, it's just how cross-platform libraries work in Rust in general, you provide a different implementation for each target platform.

Uhm, let's say you don't want to make a cross-platform example, let's say you want a pure wasm32-unknown-unknown library with an example.
#[wasm_bindgen(start)]
pub async fn real_main() {
    // your code goes here
}

fn main() { }

is longer then this:
#[wasm_bindgen(start)]
async fn main() {
    // your code goes here
}

As for cross-platform:
#[wasm_bindgen(start)]
pub async fn main_js() {
    call_init_function().await;
}

#[tokio::main]
async fn main() {
    call_init_function().await;
}

is longer then this (at least less duplicate code):
#[cfg_attr(target_arch = "wasm", wasm_bindgen(start))]
#[cfg_attr(not(target_arch = "wasm"), tokio::main)]
async fn main_js() {
    call_init_function().await;
}

When creating cross-platform libraries or applications, it is completely normal to have two implementations: one for Wasm and a different one for everything else.

This is not true at all in my experience, certainly this applies to a lot of libraries and applications. But there are tons of libraries that provide abstractions that make it seamless for users not to have two implementations. Really the example you have posted is great, getrandom is used in random, users of random have a completely seamless cross-platform experience. In fact a lot of libraries in my experience put a lot of effort to be as seamless as possible.

I'm not sure why there is such a big misunderstanding here. Your arguments aren't wrong, I agree with almost all of them. I am arguing that there is an improvement that can be made here. It's small, but it does exist.
If I understand your argument correctly, you are trying to tell me that there are ways to solve this without the improvement I'm suggesting here. I completely agree.
I think you are also arguing that basically adding cross-platform code is inevitable. I mostly agree.
Again, only because there are other ways, doesn't mean we shouldn't try to improve. Only because cross-platform code is inevitable, doesn't mean we shouldn't try to minimize it.

If you compile it in the correct way (using wasm-pack or the Rollup plugin), then you don't need the fn main() { } at all, so your code looks like this:
#[wasm_bindgen(start)]
async fn main() {
    // your code goes here
}

The only reason why you added in the fn main() {} is because you are trying really hard to compile it as a bin (which is not idiomatic for wasm-bindgen), but if you simply compile it as a lib (using cargo build --lib) then the problem disappears completely.

is longer then this (at least less duplicate code):
#[cfg_attr(target_arch = "wasm", wasm_bindgen(start))]
#[cfg_attr(not(target_arch = "wasm"), tokio::main)]
async fn main() {
    call_init_function().await;
}

That only works if you don't have a return type, wasm-bindgen must support main with a return type (like Result).
So how will your suggestion work with a different return type?

And in any case, I think your code is far less readable than just having two separate functions. Those attributes are a mess to understand.
Having separate functions also makes it very easy to support different runtimes:
// lib.rs
#[wasm_bindgen(start)]
pub async fn main_js() -> Result<(), JsValue> {
    call_init_function().await;
    Ok(())
}

// main.rs
#[cfg(feature = "tokio")]
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    call_init_function().await;
    Ok(())
}

#[cfg(feature = "async-std")]
fn main() -> Result<(), Box<dyn std::error::Error>> {
    async_std::task::block_on(async {
        call_init_function().await;
        Ok(())
    });
}

And in particular, it is idiomatic for async-std to use block_on (which doesn't work at all with your proposal).
Your code is very brittle, unidiomatic, doesn't support Result, and is also harder to read. The extremely tiny amount of extra code needed to have 2 mains is completely worth it.
In addition, your code does not work with wasm-pack or the Rollup plugin. But if you structure things in the correct idiomatic way, then everything works perfectly.

I am arguing that there is an improvement that can be made here. It's small, but it does exist.

Your suggestion is much more than just adding in support for async fn main. All of the Wasm tooling would need to be changed to support it. And because bin code has a lot of extra filesize bloat, we are avoiding that until rustc fixes that problem.
Rust already has a reputation of producing large filesizes, we don't want to make that reputation worse by supporting bin crates until that rustc bug is fixed.
You are trying to do things in a very weird, and unsupported way, and so of course you're going to run into problems. If you simply compile things in the correct way (the way that wasm-bindgen and the Wasm tools have been designed to work), then there is no issue.
Like I said before, users are not supposed to be using the wasm-bindgen CLI, it is low-level and for internal use. You will have a much easier and happier time if you use the correct tools (wasm-pack, or the Rollup plugin).

I don't think compiling binaries as a lib is the "correct" way. wasm-pack, webpack, etc all are built around libraries.
If you were to build a pure WASM binary, say with Trunk, it's not unreasonable to have a binary crate (side note: all Yew examples and trunk examples are structured this way). There are certainly valid cases where async fn main is wanted in a WASM package that is compiled as a binary crate.
It's better to supposed this use case than not. Adding a #[cfg(...)] on fn main is better than having a fn main, fn main_js

The only reason why you added in the fn main() {} is because you are trying really hard to compile it as a bin (which is not idiomatic for wasm-bindgen), but if you simply compile it as a lib (using cargo build --lib) then the problem disappears completely.

I have specifically tried to avoid arguing about this, which is why I mentioned Cargo examples. Cargo examples can't be simply made libs, it's unsupported, it will create compile errors if you don't specify a main function.

So how will your suggestion work with a different return type?

An error.

Yes, that's because they provide 2+ implementations. So if you want a nice seamless experience for your library / application, then you must do the same.

Winit is a good example of a huge library that is surprisingly seamless. Wgpu is not completely seamless, but the cross-platform code required to tack on is quiet minimal in comparison.
Again, this is about best-effort, not about perfect.

And in any case, I think your code is far less readable than just having two separate functions. Those attributes are a mess to understand.

Sure. I can agree with that actually.

Having separate functions also makes it very easy to support different runtimes:

I don't understand this argument. Sure, that's great, but you don't always need different runtimes.

And in particular, it is idiomatic for async-std to use block_on (which doesn't work at all with your proposal).

I don't get at all what you are trying to say here. async-std also has a macro for main: https://docs.rs/async-std/latest/async_std/attr.main.html, if that is what you mean?

Your code is very brittle, unidiomatic, doesn't support Result, and is also harder to read. It is not worth it at all just to save a small handful of characters.

I don't understand how it's brittle. It doesn't have to support Result. It's worth it for me.

In addition, your code does not work with wasm-pack, the Rollup plugin, the Webpack plugin, or other Wasm tools. But if you structure things in the correct idiomatic way, then everything works perfectly.

I don't use wasm-pack or Rollup plugins or any of the other stuff you mentioned. I use wasm-server-runner. For production code I have written my own small tools who just pass it through wasm-bindgen, wasm-opt and SWC for minimization.
I understand if the way you use wasm-bindgen doesn't really align with how I use it, but wasm-bindgen is an incredibly important library for the Rust ecosystem, it should support a lot of use-cases.

@hamza1311 I don't think compiling binaries as a lib is the "correct" way.

I'm sorry, but you're wrong. Even for creating applications, you are supposed to compile wasm-bindgen with --lib. That is how it has always been, and it will continue to be that way until rustc fixes the issue with bloated bin code.
wasm-pack (and the Rollup plugin / Webpack plugin) are the officially supported ways to compile Rust to Wasm. Trunk is not officially supported, it is a third-party system which does its own (unidiomatic) things, it is not compatible with the wider Rust Wasm ecosystem.

There are certainly valid cases where async fn main is wanted in a WASM package that is compiled as a binary crate.

Every use case can use async fn main_js instead, as intended.

It's better to support this use case than not.

We want to push users toward doing the correct thing. If users start compiling bin crates, they will complain about large file sizes (yes they have complained in the past).

That's true in a world in a world where Trunk doesn't exist.

Trunk has a lot of issues, it is not production ready. And it also produces very inefficient unoptimized code.
I think it's unfortunate that some people are using Trunk, because then they blame Trunk problems on Rust Wasm, even though it's a problem with Trunk only.
I have seen many people saying that "Rust Wasm produces huge files, Rust Wasm is super slow", even though that's not true, it's a problem specifically with Trunk and Yew.

Rust's philosophy is to be unopinionated and we should stick to that.

It's the complete opposite, Rust is an extremely opinionated language. There is only one package manager, one build system (cargo).

@daxpedda I have specifically tried to avoid arguing about this, which is why I mentioned Cargo examples.

It is not possible to run Wasm code directly with Cargo, so things like cargo test, cargo bench, cargo run etc. don't work, and have never worked. Rust Wasm is a different system.
In the long run it would be great to unify them, but that requires a lot of changes in rustc and cargo, it will not happen anytime soon.

An error.

So you think that wasm-bindgen should support pub async fn main_js both with and without Result, and should support async fn main without Result, but it will error with Result?
That doesn't sound very good to me, that sounds incredibly unintuitive and inconsistent.

Winit is a good example of a huge library that is surprisingly seamless. Wgpu is not completely seamless, but the cross-platform code required to tack on is quiet minimal in comparison.

You don't seem to understand my point. You keep mentioning other libraries like as if it disproves my point, but in actuality you are reinforcing my point.
My point is that all of those libraries and applications provide 2+ implementations. That's why they are seamless. You are creating a library / application, therefore your code will need to provide 2+ implementations. That's normal. I'm not talking about you using other libraries, I'm talking about your code.
Having a second (tiny) main function is quite minimal, it is not a big burden at all.

I don't understand this argument. Sure, that's great, but you don't always need different runtimes.

If you are creating a library or application to be used by other people, then having that option is good to have, it benefits your users.
So why would you choose an implementation which makes that impossible? And also bloats up your filesize for no reason? There is so little benefit to your suggestion, but so many problems and limitations.

I don't use wasm-pack or Rollup plugins or any of the other stuff you mentioned. I use wasm-server-runner. For production code I have written my own small tools who just pass it through wasm-bindgen, wasm-opt and SWC for minimization.

And by using the official tools, you make life much easier on yourself, you don't need to re-implement their features, and the tools are automatically kept up-to-date, so you don't need to worry about breaking changes.

I'm gonna stop arguing on the other points, I think we are not going to reach any form of conclusion on any of them.
I think the big point of contention here is that in your opinion wasm-bindgen should be used in a very specific way and all other ways are "wrong". I don't think there is anything to argue about here, wasm-bindgen from your perspective is just not for me then.
I will say that I wish I could use wasm-pack and all the other tools you have mentioned, but for various reasons they just don't work out for me. Over time I basically gave up on them and reduced it to the minimum of wasm-bindgen and other "non-official" tools that are as unopinionated as possible.
I feel very strongly about the fact that a library as low-level as wasm-bindgen should be as unopinionated as possible, I do believe that this is a strong point in Rust to allow for maximum re-usability, to me this is the strong point about open source.
This doesn't mean I believe opinionated libraries or applications don't make sense, I'm not making blanket statements here.

That's true in a world in a world where Trunk doesn't exist.

Trunk has a lot of issues, it is not production ready. And it also produces very inefficient unoptimized code.
I think it's unfortunate that some people are using Trunk, because then they blame Trunk problems on Rust Wasm, even though it's a problem with Trunk only.
I have seen many people saying that "Rust Wasm produces huge files, Rust Wasm is super slow", even though that's not true, it's a problem specifically with Trunk and Yew.

What issues? I've used both trunk and wasm-pack and have not experienced any issues. I just tested the binary size and the trunk binary was smaller in my test. You can test that by:

Git clone https://github.com/hamza1311/yew/
cd examples/router
trunk build --release
Checkout branch  trunk-vs-wasm-pack
wasm-pack build

dist is generated by trunk, pkg by wasm-pack:
>> ls -l dist pkg/

dist:
.rw-r--r--  281 hamza 10 Sep 02:03 index-2e4e699b9f23b3d5.css
.rw-r--r--  683 hamza 10 Sep 02:03 index.html
.rw-r--r--  34k hamza 10 Sep 02:03 router-2afdc71d0293d9ef.js
.rw-r--r-- 387k hamza 10 Sep 02:03 router-2afdc71d0293d9ef_bg.wasm

pkg/:
.rw-r--r--  248 hamza 10 Sep 02:02 package.json
.rw-r--r-- 1.9k hamza 10 Sep 02:02 README.md
.rw-r--r--   79 hamza 10 Sep 02:02 router.d.ts
.rw-r--r--   99 hamza 10 Sep 02:02 router.js
.rw-r--r--  30k hamza 10 Sep 02:02 router_bg.js
.rw-r--r-- 392k hamza 10 Sep 02:02 router_bg.wasm
.rw-r--r--  986 hamza 10 Sep 02:02 router_bg.wasm.d.ts

The binary size in debug mode, where rustc produces huge binaries, doesn't matter and should not be used as a point of comparison.

We want to push users toward doing the correct thing. If users start compiling bin crates, they will complain about large file sizes (yes they have complained in the past).

Is the existence of frameworks/libraries like Yew, Seed, Dioxus incorrect? These frameworks/libraries create binaries which are the entire web application. That is completely different from creating libraries - using wasm-pack and such - that are used by web applications build with JS.

I do not believe we are going to reach a conclusion on this and calling each other "wrong" or saying that one and only one way of doing things is the correct way is productive so I'm going to end this discussion here.

@daxpedda I will say that I wish I could use wasm-pack and all the other tools you have mentioned, but for various reasons they just don't work out for me.

That's a very serious issue! If you're having problems with the official tools, then we want to know about it so we can fix it! What issues have you had?

I feel very strongly about the fact that a library as low-level as wasm-bindgen should be as unopinionated as possible, I do believe that this is a strong point in Rust to allow for maximum re-usability, to me this is also the strong point about open source.

As I said before, the issue isn't really with wasm-bindgen. We would like to support bin crates, but it requires changes/fixes in rustc. It's an issue with rustc itself.
Similarly, we would like for everything to work seamlessly with cargo (such as cargo test, cargo bench, etc.) but that also requires changes in rustc/cargo.

That's a very serious issue! If you're having problems with the official tools, then we want to know about it so we can fix it! What issues have you had?

Personally back then I had issues with getting wasm-opt to run and running tests. I don't remember the exact details, but I'm surprised your are surprised. wasm-pack is not a small project, any sufficiently big project will have bugs or missing features that don't cover the use-cases that everybody might have.
wasm-pack has a lot of open issues that make it unusable for some people. Also wasm-pack was basically unmaintained for a very long time, it might have improved a lot in the meantime, I wouldn't know.

As I said before, the issue isn't really with wasm-bindgen. We would like to support bin crates, but it requires changes/fixes in rustc. It's an issue with rustc itself.
Similarly, we would like for everything to work seamlessly with cargo (such as cargo test, cargo bench, etc.) but that also requires changes in rustc/cargo.

I agree of course, but I'm getting the impression that you have a very non-compromising stance. In the meantime people like me just don't use the "official" way of doing things to get by. This is what I'm seeking support for.
But I think you made your stance clear that supporting anything "non-official" is in fact a bad thing.

@hamza1311 What issues? I've used both trunk and wasm-pack and have not experienced any issues.

File size is always larger, because it uses bin crates.
You cannot use npm packages with Trunk.
It does not bundle your JS code.
It does not optimize the JS code at all.
You cannot use inline_js with Trunk (which also breaks any Rust libraries that use inline_js).
It doesn't support async chunking (like Rollup and Webpack).
You can't produce binaries for different platforms (like NodeJS or Electron).
There aren't any plugins to load other file types (like JSON).
You can't use plugins to customize anything.
You can't create Chrome / Firefox extensions with it.
You can't create Workers with it.
You can't call Rust functions from JS, which is often needed in applications.
When using Trunk it will often use stale files, meaning that even if you change your files, it will keep using the old files. So you now have to manually delete the target folder in order for it to compile correctly.

JS tools like Rollup and Webpack have had an absurd amount of effort put into them. Trunk is very new, very immature. I hope that one day it will become great, but right now it's just missing too many features that you need in production.

I just tested the binary size and the trunk binary was smaller in my test.

I checked out that git repo and ran Trunk on the router example. I immediately got this error:
2022-09-09T21:36:15.100030Z  INFO 📦 starting build
2022-09-09T21:36:15.100341Z  INFO spawning asset pipelines
2022-09-09T21:36:15.244765Z  INFO building router
2022-09-09T21:36:15.244910Z  INFO compiling sass/scss path="index.scss"
2022-09-09T21:36:15.245183Z ERROR ❌ error
error from HTML pipeline

Caused by:
    0: error from asset pipeline
    1: error spawning sass call
    2: No such file or directory (os error 2)
Error: error from HTML pipeline

Caused by:
    0: error from asset pipeline
    1: error spawning sass call
    2: No such file or directory (os error 2)
>> router warning: unused config key `unstable.share-generics` in `/tmp/yew/examples/.cargo/config.toml`

So instead I tested it out on my own example:
https://github.com/Pauan/rust-dominator/tree/master/examples/counter
With Trunk I got this result: 92,394 bytes for the .wasm + .js file.
With the Rollup plugin I got this result: 62,480 bytes for the .wasm + .js file (that's a 48% reduction in file size).

That is completely different from creating libraries - using wasm-pack and such - that are used by web applications build with JS.

You are very mistaken. Tools like wasm-pack and the plugins are not only for creating libraries, they are for applications too.
In fact the Rollup plugin has explicit support for being used as the entry point in Rollup, which is specifically for applications. The Rollup and Webpack plugins are primarily used for applications, not libraries.

These frameworks/libraries create binaries which are the entire web application.

And that is also what wasm-pack and the plugins do, they can also create entire web applications, they are not only for libraries.
I personally use the Rollup plugin for all of my web applications. I've even used it to create Chrome / Firefox extensions (which is something that Trunk cannot do).

Is the existence of frameworks/libraries like Yew, Seed, Dioxus incorrect?

No, I never said that. I said that Trunk has a lot of issues and produces extremely unoptimized code. If you compile Yew / Seed / Dioxus in the official way (e.g. using the Rollup plugin) then you will get a much better result.

@daxpedda Personally back then I had issues with getting wasm-opt to run and running tests. I don't remember the exact details, but I'm surprised your are surprised.

Yes, wasm-pack has in the past had issues with wasm-opt. That has been completely fixed by the Rollup plugin.
Unit testing is very complicated, it's not very well supported by wasm-bindgen right now, unfortunately.
I actually suggest writing your unit tests with something like Karma or Jest or Playwright or something like that.
I think it should be possible to create a system which would convert #[wasm_bindgen_test] into a JS test runner like Karma.

wasm-pack has a lot of open issues that make it unusable for some people. Also wasm-pack was basically unmaintained for a very long time, it might have improved a lot in the meantime, I wouldn't know.

Yes, there was some bad personal drama that happened with wasm-pack. I believe most of the issues have been fixed, and the Rollup plugin is well maintained and does not have any known issues.

But I think you made your stance clear that supporting anything "non-official" is in fact a bad thing.

Imagine that you encountered a bug with cargo. Instead of reporting that bug, you decided to create your own custom build tool which calls rustc manually.
Then you encounter some issues, because you're using rustc in very strange ways that the Rust developers never intended. So you go onto the Rust bug tracker and file a bug report asking for them to support your specific way of using rustc.
Of course the Rust developers will be very confused, and they're going to ask why you're not using cargo, because cargo is what users are supposed to use. Everything is designed around cargo.
And instead of changing rustc to support your weird way of doing things, the Rust developers would much rather just fix the cargo bug which was preventing you from using cargo in the first place.
The situation is very similar with wasm-bindgen.
Have you tried using the zip that I gave you earlier? I have put in quite a lot of effort into making sure that the Rollup plugin is fast and bug-free.

For some perspective, I think the use-cases that you have are just completely different then what, for example, I have. Like more then half of the things you listed in response to hamza1311 is stuff that I don't require and don't want to pay the cost for.
I'm most definitely not going to use Rollup unless somebody puts in the effort to convince me of this, just taking a short glance at it makes it very unattractive to me. The same really applies to most of the tools you talked about and the zip file you linked.
This is why I find these tools unattractive:

I'm trying to minimize the amount of langues and tools that I use for my project as much as possible.

Except for Cargo and all the tools that come with it, I only use Taplo and cargo-spellcheck as external tools.
All my configuration files are TOML. The only exception are the CI files for GitHub actions that are written in YAML.
The README file uses markdown.
Everything else is Rust.

I prefer to use things that are written in Rust then anything else.

I can look at the code and understand it, even write PRs.
I don't have to install NPM or other compilers I have no clue about and don't want to spend additional time learning.

I try to use things that at best cover my use-case and nothing else to reduce bloat.

I had a terrible experience with wasm-pack, to me the size of the project is just too big compared to the amount of maintenance it gets. I also barely need any of the features it provides.
Rollup requires more setup and understanding and doesn't seem to provide additional value for my use-case.

As I mentioned before, wasm-server-runner does everything I need during development and for production I have my own toolchain that does exactly what I need and not even a tiny bit more, I know what it does and I can change and adjust it anytime.

I think your argument about Cargo was poor and I honestly consider it being done in bad faith.
I use Cargo because it works for me, if it wouldn't I would fork it and use that. I don't use wasm-pack because it doesn't work for me, so I found alternatives. I'm working with Web Workers at the moment, I had to fork wasm-bindgen because I required some adjustments to get things working (I provided PRs for those).
As you can see here I'm quite active GitHub, I write up issues and provide PRs almost on a daily basis. But this is really irrelevant. I'm privileged to have this kind of time and motivation, others don't, they just fork stuff or look for alternatives when they need it. There is nothing wrong with that in my opinion.
I consider it also alright that you don't share this opinion, clearly you have a vision for wasm-bindgen and related projects that I just don't share and that's okay. I'm just providing feedback here, hope it helps.

@daxpedda I can definitely sympathize with the desire to do everything in Rust. Before wasm-bindgen existed, I contributed to cargo-web, which was an all-Rust toolchain for compiling Rust to Wasm. It was a very nice experience.
Originally our plan was to do a lot more in Rust. But the unavoidable fact is that you are compiling to Wasm + JS. Although I personally quite dislike the JS ecosystem (and JS tooling in general), they are currently the best tools available for the compilation and optimization of Wasm/JS.
An incredible amount of effort has gone into the creation of JS tooling, the Rust Wasm tools can never compare to it. So if you want to do anything more complicated than just "compile Rust to Wasm and run it", then you're going to need JS tools. JS tooling is basically mandatory in any sort of production setting. You can only avoid JS tools in very simple use cases.
And so after examining the available options, the design that we settled on was to use wasm-bindgen to handle the Rust side of things, and to use JS tools to handle the JS side of things. That means each tool can do what it does best, and so users get the best end result.
You talk about "supporting every use case", but that's exactly what we are doing. There are tons and tons and tons of use cases that just cannot be supported by simple tools like Trunk (or custom build systems). By leveraging the existing JS tools we can support those use cases basically "for free".
Unlike your custom build system, which is only for you, we have to support a lot of people, and a lot of different use cases.

I try to use things that at best cover my use-case and nothing else to reduce bloat.

That's not a bad position to take, but I think bloat in build tools is far less of a problem compared to bloat in the actual compiled code.
Cargo and the Rust stdlib have a ton of features that I've never used, but I wouldn't call them "bloat", because none of that bloat makes it into the final compiled code. And in many cases that extra "bloat" in the build tools means smaller or faster compiled code, which is ultimately a good thing for the users.

I think your argument about Cargo was poor and I honestly consider it being done in bad faith.

I don't really understand that, the situations are almost identical, it's a very good analogy.
rustc is a low-level tool that just compiles individual Rust code, it doesn't do anything fancy.
cargo is a high-level tool that handles package management, building, optimization, etc. basically it's the glue code that makes everything work.
wasm-bindgen is a low-level tool that just compiles Rust Wasm, it doesn't do anything fancy.
The Rollup plugin is a high-level tool that handles package management, building, optimization, etc. basically it's the glue code that makes everything work.

There is nothing wrong with that in my opinion.

When you just need to Get Things Done, that's fine, but reporting issues helps everybody, not just you. If the issue can be fixed at the source, then it can benefit millions of people. Economies of scale are important.
That's how humanity progresses forward, not by each person reinventing the wheel, but by people working together to make something better. That's why we don't have a dozen different forks of cargo. Having one official way to do things is really helpful (whether it be cargo, rustdoc, rustfmt, etc.). That's the entire philosophy of Rust.


Switch to alternative pesq implementation

It's a fork of the original pesq repo that does proper error handling (rather than simply exiting with exit(1); from C code).
cc FYI @mpariente

Recommended by original author here https://github.com/ludlows/python-pesq/issues/12#issuecomment-645097746

@jonashaag Thanks for the PR.
Do you know why @ludlows does not merge that Repo?
It would be cleaner when the PyPI version will be updated.

No idea, sorry

Or simply switch to https://github.com/vBaiCai/python-pesq, which I have worked with in the past and didn’t cause any trouble

When we added pesq, we considered three implementations:

Our own implementation that used subprosess

+ Zero modifications of original code
- Need file system
+ Can run in Parallel

ludlows

+ Python wrapper
+ Supports all features
- Modified PESQ source code
- Cannot run in Parallel

vBaiCai

+ Python wrapper
- Modified PESQ source code
- Disabled wideband
- Cannot run in Parallel

Since vBaiCai does not support wideband it is not an option that I want to choose.
I am not sure in which source code it was, but in one someone changed the PESQ algorithm.
The intention was most likely to stabilize, but it changes the actual values.
This disables the ability of the comparison between papers and I want to have the score that the original PESQ produced.
We decided against our own implementation, because of the file system overhead.

You're right, I just checked, the vBaiCai version has modified PESQ source.
Maybe I'll create my own wrapper... I mean the wrapper source codes look really simple

What are we going to do with this problem?

I was hoping that https://github.com/ludlows/python-pesq fixes this problem.
It looks like a huge modification of the source code is necessary and I don't know when they fix it.
It is problematic, that the owner does no longer use the code.
One solution would be to release our internal code that uses subprocess.
But this introduces a file writing and subprocess overhead, so I am not sure, if it is better.
Also, it needs at the moment gcc.

it is a little complicated to change the code to a thread-safe version which supports multi-threads as well.
right now, I am not sure the priority among thread-safe version and the one supporting to error handling yet.

As far as I know, your pesq code is thread safe, because the python GIL is not released.
Letting the code release the GIL may be difficult, because the original code uses global states.

yes. but it means the code cannot running in parallel since the GIL exists.
the easy way to accelarate computing in python is subprocessing.
so handling the errors well seems more important, right?

Yes, subprocess allows to execute the computation in parallel. An another alternative is multiprocessing.
I personally use most of the time MPI, where I calculate PESQ, there I don't care about the GIL.
Subprosess also handles the problem with the error handling. At least partially.
For the error handling it would be nice, when an exception is thrown. That simplifies the bug search


Upgrade 1.6.1 or 1.6.2, unable to start, frequent flashing & restart

Describe the bug

To Reproduce
No response
Expected behavior
No response
Diagnostic report (REQUIRED)
No response
Screenshots and additional context (optional)
No response

+1

Duplicate of #1229


Error when typing Unicode on the address bar

System Details

OS: Windows 11
Thorium Version 126.0.6478.231 (Official Build) (64-bit)

Problem
Error when typing Unicode on the address bar using Evkey. https://evkeyvn.com/
Screenshots
When I type
When I type "dd" it must become "đ"

On chrome it works fine

Additional Notes
Link download Evkey: https://evkeyvn.com/

I will switch to chrome until this problem is fixed.

I realized that the issue only appear when sign in. If I use guest profile, the problem is gone


Change to RTD sphinx theme on RTD

I changed the astroplan Sphinx theme to RTD following the instructions on RTD and the wcsaxes example:
https://github.com/astroplanners/astroplan/commit/29fd9a8dcbd53c7e5b9e4dfa6fde73167452d90d
It works locally, but on RTD it still uses the Astropy theme for some reason:
http://astroplan.readthedocs.org/en/latest/
Wiping and re-building from scratch doesn't help:
https://readthedocs.org/builds/astroplan/2643582/
@astrofrog @eteq – Any idea why this doesn't work?

Haha ... it just changed to the RTD theme a minute ago.
Looks like there's a few-minute delay between the build finishing and the docs page updating ...
Sorry for the noise!


Updating  the current user.

Thanks a lot for resolving previous issues so quick and efficient.
Especially the new feature which allows to send an email to the user to verify the email address.
But there is a problem. When the current  user clicks the link provided in the email it is not easy to check that verification state of the user. FirebaseUser object is cached so in order to check verification state of a user, android developer will call .getCurrentUser().reload() for an update. So that .reload() method is really missing at the moment. Thank you very much for your work.

There is workaround . To force firebase to update user the following code will work:
firebaseUser.updateEmail(firebaseUser.getUserInfo().getEmail(), new CompleteCallback() {
@Override
public void onSuccess() {
GdxFirebaseUser firebaseUserNew=GdxFIRAuth.instance().getCurrentUser();
log.debug("new email:"+firebaseUserNew.getUserInfo().getEmail());
log.debug("email verified"+firebaseUserNew.getUserInfo().isEmailVerified());
}
                @Override
                public void onError(Exception e) {

                }
            });

Mhmm okey! Thanks for the report again. I'm sorry I did not answer sooner but I was out of any working for sometime.
You will see .reload() method in the next release, for sure!


access docker containers.

Is your feature request related to a problem? Please describe.
I can't develop because all development environments are docker.
Describe the solution you'd like
I want "dev containers" of "visual studio code" in this editor as well.

Duplicate of https://github.com/lapce/lapce/issues/1481


Removed console.log message from events page

🛠 Fixes Issue
Closes https://github.com/OSCode-Community/OSCodeCommunitySite/issues/20
👨💻 Changes made
Removed the console.log from the events page
📷 Screenshots

Hey Thanks for contributing to our repository, we will review and merge it soon :)

Hey Thanks for contributing to our repository, we will review and merge it soon :)

Sure

Can you please add the GSSOC'23 label to this?


CheckBox: label position top/bottom

Feature request type
Enhance component
Component name
CheckBox
Is your feature request related to a problem?
I'm missing the possibility to position the checkbox label above or below the checkbox.
Describe the solution you'd like
I already build a prove of concept for this request.
my solution in my fork

Have you seen this feature anywhere else?
No response
Describe alternatives you've considered
No response
Pull Request

[X] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

See PR #5650

Thanks @TDroogers for your contribution.
I am not sure about this UI though.
Checkboxes generally have labels inline horizontally and I think its for a reason.
If a label is above or below it seems disconnected to me.
@JonBunator whats your thoughts.

I need it in my design like the image below.

I can also revert the docs change and only have it in the API documentation.

I can also add the possibility to add your own class / style to the label.
That way I can solve the issues I have without pushing this option into MudBlazor.

I also just realized that enum LabelPosition is used for multiple components.

I have a new proposal: In this branch

Thanks @TDroogers for your contribution. I am not sure about this UI though. Checkboxes generally have labels inline horizontally and I think its for a reason. If a label is above or below it seems disconnected to me.
@JonBunator whats your thoughts.

Looks a bit weird to me. But I guess it makes sense to add it. Other libraries also have the option


refactor: Store keys

Describe your changes
This PR refactors the store key helper functions.
Link issue(s) fixed

#1442

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have verified new and existing tests pass locally with my changes.
[x] I verified whether it was necessary to increment the database version.

I think this is risky having so many changes in one PR, however I also want to see this change go through. It is very likely that any issue would be caught in the unit tests first, as the move towards specificity (array of bytes of known size) easily panics if incorrect.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_26cigw9ylr/clone/recipe/meta.yaml:19: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_26cigw9ylr/clone/recipe/meta.yaml:44: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_26cigw9ylr/clone/recipe/meta.yaml:44: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_26cigw9ylr/clone/recipe/meta.yaml:44: missing_dev_url: The recipe is missing a dev_url
Errors were found


JsonApiParser is deprecated

Their README says the project has been deprecated.
They advertised jsonapi-rb / jsonapi-parser as a replacement, but that's more of a validator than a usable client-library, so I just deleted this entry.

Ping @beauby. If we remove this, do you want to link any replacements instead?

I made one that could replace JsonApiParser. https://github.com/json-api/json-api/pull/1586


update gisce/ooui to v2.4.0

Automated changes by create-pull-request GitHub action

:tada: This PR is included in version 2.5.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.6.0-alpha.3 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Wrong size of headline at export to PDF, HTML or anythign else

Describe the Bug
We think, that we found an error, when  you export sites as PDF, HTML or anything else. The size of the headline is the same like the chapter. We checked this with the markdown file and there we found that every part (headline, chapter and booktitle) has the same size. You can see this in a markdown viewer. Is this right? Normally the chapter, booktitle and headline should have a different size.
Steps to Reproduce
Create a book, next create a chapter, now create a site. Export this as HTML and as Markdown file. Use a markdownviewer to check the code.
Expected Behaviour
You will see that every title / chapter / headline has the same size. In the viewer you will see, that every part has a # in the front. Normally it should # for the book title, ### for the chapter and ###### for the headline of the page.
Screenshots or Additional Context

Browser Details
Edge Version 114.0.1823.43 (Offizielles Build) (64-Bit)
Exact BookStack Version
BookStack v23.02.1
PHP Version
8.2.6
Hosting Environment
Linux (ubuntu 20.04)

Thanks for raising, but I'm not really sure what the suitable solution is, especially for markdown.
Users already have access to the full range of headers in the editor, so there's not really room to add some at the top level.
Could add complexing parsing and altering to squash at the higher-header levels as that's more likely to have unused space, but it will add fair complexity and still results in an non-ideal solution.

Thanks for your answer. We thought, that this is an failure. If that is to complex to implement a different size this topic can be closed.